0

We are trying to move from a monolith application to a microservice architecture faced by a spa application. One of the reason, is that we want to expose some services of our business to partners and another reason is to build a better user experience via an spa application.

In the old application I had a webapplication where I could register an employee (name, surname, empno, adress...), choose his company from a dropdown list and in the same time create an account for this employee in a backend erp : think of this application as a backoffice one. All data was on a single form, when the user submit the form : the backend server save the employee record, and if successful create an account in the erp system.

In order to manage the authorization for this application : the url to register an employee in the webapplication was accessible only if the loggued user have a role that able to handle the "RegisterEmployee function".

Now in my spa application, I need to call :

  • a microservice for verify if the employee is not already registered ,
  • a microservice to have the list of the known companies
  • a microservice to create the employee account in our erp

I was first trying to define the roles allowed in each microservice, but it seems weird because : - all my microservices could be reused in different scenarios - and they don't necessary share the same list of roles...

In fact I am in the same situation as in this other question : SOA/Microservices: How to handle authorization in inter-services communications? but as the author of the question I have not found any solution yet.

I had read about api gateway lately, and perhaps it is the way to go, but I am not sure how ? Does this mean that my microservices do not have to be aware of any authorization management ?

Dypso
  • 231
  • 1
  • 6
  • 2
    There are many ways to skin this particular cat but a good place to start would be reading up on claims-based authorization. – Ant P Jan 17 '19 at 14:35
  • 3
    Maybe offtopic, but if you have to call 3 services to fulfill a use-case, you are probably doing microservices wrong. You may be using "microservices" as plain database tables. – Robert Bräutigam Jan 17 '19 at 14:43
  • @Robert Bräutigam, are you suggesting that I should have only one microservice for the use-case (ie for the UI and use-case management) ? For example a "RegistrationEmployee" service ? Why not, but in all case this registrationEmployee service should know about employee data, company data,... So should define any authorization attribute on this data services ? – Dypso Jan 17 '19 at 14:50
  • @AntP, thank you! Any good links? – Dypso Jan 17 '19 at 14:54
  • @Dypso I'm reluctant to give generic advice about your application that I obviously don't know. What I do know is, that microservices are supposed to implement specific, independent business-functions or business use-cases. They are not CRUD data services, i.e. tables over http. The difficulty is to create microservices that are independent (i.e. don't need others to work, especially not data), but still implement business functionality. – Robert Bräutigam Jan 17 '19 at 15:43
  • We use JWT (https://jwt.io) and include the roles in the token. That keeps all the information we need in the token itself so we don't need to make further microservice to microservice calls to ensure they have permissions to do things. – Berin Loritsch Jan 17 '19 at 18:10
  • @BerinLoritsch : how do you define your roles ? have you got some roles shared by multiple microservices ? – Dypso Jan 19 '19 at 21:27
  • @Dypso, JWT will allow you to include the roles or other metadata embedded in the token. It's up to you to define what those roles are. You can use standard keys or define your own (example: https://jwt.io/#debugger-io?token=eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiaWF0IjoxNTE2MjM5MDIyLCJyb2xlIjpbImZvbyIsImJhciIsImJheiJdfQ.9uk-h6q_gfw41o8h7uH-osiTwD-RlbJNH2NMuaeLlWE) – Berin Loritsch Jan 19 '19 at 21:54
  • See the intro for a more complete overview: https://jwt.io/introduction/ – Berin Loritsch Jan 19 '19 at 21:55
  • @BerinLoritsch : I have read the intro, and I understand that I could compose how I like the content of the jwt by adding standard or custom keys... But my problem is I do not know how to fill all the claims when there are transitive dependencies between microservices... – Dypso Jan 19 '19 at 22:48
  • Essentially, the token is presented with every request to each microservice. The microservice only needs to make use of that information. Dependencies between microservices shouldn't matter. As others have suggested, perhaps you have divided the responsibilities in a way that complicates things more than necessary. – Berin Loritsch Jan 19 '19 at 23:43
  • @BerinLoritsch : May be my question is not well formed : I have the same problem as in this other post : https://softwareengineering.stackexchange.com/questions/344999/soa-microservices-how-to-handle-authorization-in-inter-services-communications – Dypso Jan 20 '19 at 11:05
  • @Dypso that's probably related to Robert Bräutigam's comment - a scope should give you enough permission to perform action(s) associated with that scope - you shouldn't really have implicit transitive dependencies on other scopes. If you do, then your client should just be requesting all of the relevant scope(s) for a particular action from the authorisation server and the token should include all of them. – Ant P Jan 23 '19 at 13:36

0 Answers0