title: SOA Service Design / Authentication
body: <p>I'm rather new to SOA and therefore experimenting around.</p>
  
  <p>Currently, the part that creates the biggest problem to me is authentication, my current thought about it involves the following:</p>
  
  <p>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.</p>
  
  <p>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.</p>
  
  <ol>
  <li><p>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. </p></li>
  <li><p>The authentication service keeps all session information in ram and responds without the db roundtrip to the requests.</p></li>
  <li><p>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.</p></li>
  </ol>
  
  <p>I think the first approach creates too much stress on the authentication service / db but takes the least effort to implement.</p>
  
  <p>The second is still very easy to implement but the stress on the authentication service remains almost the same.</p>
  
  <p>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.</p>