SOA Service Design / Authentication

Question

I'm rather new to SOA and therefore experimenting around.

Currently, the part that creates the biggest problem to me is authentication, my current thought about it involves the following:

The client sends some kind of authentication message to the authentication / user service, this service queries the db and if the user is found and the password is valid, it will respond with a session id, this id will be used in all further requests of this client.

This seems rather ok to me but I don't know how I should handle the requests to other services, I thought of three different approaches.

1. Every service asks the authentication service if the session is valid and if so, what roles the user is in. The authentication service looks in the db and replies accordingly.

2. The authentication service keeps all session information in ram and responds without the db roundtrip to the requests.

3. The authentication service sends an authorized message to an esb, the esb forwards this authorized message to every service and these services cache it. No further requests to the authentication service would be necessary. If the user logs out or his roles change, another message would be send around and processed by all services.

I think the first approach creates too much stress on the authentication service / db but takes the least effort to implement.

The second is still very easy to implement but the stress on the authentication service remains almost the same.

The third is a little more complicated to implement but would has reduced response time as no trips to the authentication service take place. Though, if there are too much session information this approach would just fail and scalability is hardly given.

Answer 1

The best approach should be like this if all the services are internal,

1. The authentication service issues a token the the service client.
2. Service client includes the token in the SOA message wrapped in WS-Security or something similar.
3. The service should validate the token with authentication service before providing the service.

For external services, I suggest you look at federated solutions like SAML.

Answer 2

Don't do premature optimization. Your option no. 3 which you acknowledge will be more complicated to implement is unnecessary. Choose option no. 2 if that's what you can implement fast. You can profile later and change it, but I'd bet money that you won't have a 'bottleneck' when going with option 2.