14

I'm exploring basic service oriented architecture and I'm wondering how to best handle user authentication throughout the services.

As a very simple example, suppose we have a blog app that calls out to two other services:

  1. A user/auth service for storing user data and exchanging credentials for an access token
  2. A posts service for managing post data

Let's say a user of the application is attempting to delete a particular post and that only users with an "admin" role are allowed to do so.

The following requests would need to be made:

  • app -> auth

    Authenticate the current user (via some sort of token). If the token is expired the app could redirect the user to a login form, etc.

  • app -> posts

    Delete the post.

  • posts -> auth

    Before a post is deleted, the post service needs to make sure the requesting user has permission to do so. Authenticate the current user (via token) and make sure they have the "admin" role.

This is an overly simple example but I'm curious how folks are dealing with auth throughout their services. It seems likely that each service would need to make a separate call to the authentication service in order to authorize the request. Is this the case? Are there better ways to handle auth in this kind of SOA?

Thanks!

scttnlsn
  • 2,976
  • 1
  • 33
  • 39

1 Answers1

8

You can implement an identity provider - Once a user authenticates with the authorization/authentication service she should get a token that identifies her. This token can identify her (roles/claims) and signed by the authentication/authorization service private key. When a service gets a security token and it is signed by a trusted authority it doesn't need to go to the authentication/authorization service again.

If your system has a higher security requirements (e.g. at the user level) you may need either elaborate claims or to access the authorization system on each request. I worked once on a system where certain types of info required authorization on every access and other types were ok with role based security - your millage may vary.

Arnon Rotem-Gal-Oz
  • 25,469
  • 3
  • 45
  • 68
  • Are you suggesting that the token itself include a user's roles? – scttnlsn Apr 28 '13 at 19:24
  • 1
    It all depends on your security requirements. if for the token lifetime you can live with not handling a revoke of authorization then you can use it. In cases where you can't afford that you need to authorize on each request. Note that if the identity provider and the services that use it are deployed on the same servers the overhead can be reasonable. e.g. policy agent in OpenAM https://wikis.forgerock.org/confluence/display/openam/Authentication+and+Authorization+Overview – Arnon Rotem-Gal-Oz Apr 28 '13 at 19:47
  • 2
    @Michael instead of what? OpenID is for authentication and the question is about authorization. Also OpenAM is just an example there are other ways and technologies – Arnon Rotem-Gal-Oz Apr 29 '13 at 08:58