3

I'm designing a microservice based application with two API endpoints, and one of them is for user access. Users, authenticated with JWT, can belong to different organizations which are in turn organized hierachically. Each user can have some role, which are defined for every organization type; the combination beetween organization and roles define which API could be accessed from user (method and resource) . In conclusion, it can become a mess!

There are several libraries that provide ACL features, but i'm wondering where to put them: the first solution seems to be the API gateway, which should call a component for each request.

-the JWT includes the list of role IDs for the user -API gateway validates JWT and uses the role Ids to lookup in a table where each role has a list of permissions (ex. can POST /users) -if the role matches with request, the latter is forwarded to the right service; otherwise, the gateway responds with 403

The other options is to put a 'auth-service' into architecture. The gateway simply forwards all the requests delivered to the right service, each service (which might depend on a common library) sends the token to the auth service and request grant to satisfy request. In this case, the auth service is the 'right service' for all requests under the /auth resource, gives login/logout, token refresh and registration of new users (like when you click on the link provided into sign in mails)

The first solution provides for a 'fat gateway' which has a tiny layer on logic, but enforces all the service to respond only to secure calls, factorize out all the authentication/orization logic and not adds dependencies beetween services but

  1. is it the right way to do it?
  2. are there api gateway implementations that provide that features
  3. there are some other advantages/disadvantages in both approaches that i don't see

thank you for the answers!!!

Carmine Ingaldi
  • 856
  • 9
  • 23
  • 1
    Perhaps the concept of a PolicyServer is something that may interest you: https://leastprivilege.com/2018/01/17/announcing-policyserver/ Also check the video of the presentation: https://vimeo.com/223982185 –  Aug 25 '18 at 07:28
  • Thanks! I'll give a glance! – Carmine Ingaldi Aug 30 '18 at 08:38
  • Have you settled on a solution @sscnapoli1926 ? I'm reflecting upon the exact same thing at the moment – osteel Nov 19 '18 at 16:58
  • @osteel , for now, we decided to factor-out the auth-service: since we have observed the thight coupling with api gateway, we have planned to transform it in a plugin to be added to our gateway, implemented with express-gateway (https://www.express-gateway.io/). When the job will be done, i'll share here impressions and results! – Carmine Ingaldi Nov 27 '18 at 15:38
  • @sscnapoli1926 thank you for getting back to me and for sharing your approach. I can see the appeal of extracting authorization into its own component, so microservices don't need to deal with it. On my end I am leaning toward a third approach, which would consist in leaving authentication with the gateway indeed, but having each microservice responsible for its own authorization rules. – osteel Nov 28 '18 at 15:39

1 Answers1

0

I'm back to share my toughts about choices made around the subject of the post. The way that i followed is

API Gateway is aware of auth data sent along with requests (the "Authorization header" in practice) and does verifications. JWTs carry all necessary information, so the api gateway can apply its policies that are unknown to downstream services.

In my architecture there is some RBAC, nothing to biig to nont be put in a jwt, so we moved access control logic on the gateway. We adapted a custom nodejs library as plugin, but i have to admit that has messed our gateway and we found out that authz configuration is slow and error prone. On this side, we are paying the lack of integration with main configuration info. it would be useful something like

routes:
  - route1:
      path: /foos/:fooid/bar
      downstreamService: http://foo.cluster
      authz:
        readerRole:
          - GET
        writerRole:
          - POST
        all:
          - OPTIONS

However, Api gateway cannot do everything on its own: need to contact wht i call "identity provider" services, those who encapsulates entitites that model the concept of "consumers" into platform: user, device, app. Our api gateway performs a GET on identity based on JWT data to verify that identity exists and everything is all right. Additionally, token generation/refresh is not api gateway concern, but there is an auth server (one is standalone, another one still embedded into monolith) that is conctaced. All this generates a lot of load, but this can be easly mitigated with "identites" caching. be just aware to invalidate the cache when identites are mutated, or at leat try to use as less information as possible, so that you can just care about identity deleting

Next steps for us will be to make/buy a more structured auth server, which will keep to be integrated with gateway but able to scale independently and more clear and easy to configure, probably with some sort of UI

As cloud native fan, i was also looking at istio that has, among other thing, auth features, but still i need to understand if is suitable with my approach that requires the ability to do a little customization

Carmine Ingaldi
  • 856
  • 9
  • 23