Jul 23rd, 2012, 02:33 PM
clustered auth server?
Using the tonr/sparklr samples, I started separating the auth server and resource server into different projects as a POC when I began to realize how a single auth server is also a potential single point of failure. If I were to deploy the auth server project to a clustered environment (with, say, two nodes, AuthA and AuthB), are there any potential issues where subsequent requests to "/oauth/token" that are served by different auth server nodes could fail? If so, are there constraints I should keep in mind to prevent this? Has anyone tried this implementation approach?
Keep in mind the root part of the URL would not be different for AuthA and AuthB, i.e., the resource servers and clients would only "talk" to 1 auth server. A reverse proxy/load balancer would then route the request to the auth server nodes in an alternating fashion.
Last edited by jrod; Jul 23rd, 2012 at 02:38 PM.
Reason: added clarity
Jul 23rd, 2012, 03:53 PM
The token endpoint needs a shared AuthorizationCodeServices if you need auth code grants. The authorize enpoint needs more careful state management - it uses @SessionAttributes to store state between the initial auth request and the code or token grant. That's a Spring MVC strategy (SessionAttributeStore) so not really OAuth specific. You can use sticky sessions with the default implementation, or add your own back end.
Jul 24th, 2012, 11:59 PM
I guess if you choose persist the auth request in session in order to not use session stuff, you should eventually override the AuthorizationEndpoint framework class.
Originally Posted by Dave Syer
Jul 25th, 2012, 03:12 AM
@enkhchuluun I don't think that's right. The AuthorizationEndpoint doesn't explicitly interact with the HttpSession anywhere.
Aug 12th, 2012, 07:27 PM
I've implemented an instance of JdbcAuthorizationCodeServices to serve as a shared AuthorizationCodeServices for the clustered token endpoint. Is this sufficient?
Originally Posted by Dave Syer
As for the authorize endpoint, I'll explore whether we can enable sticky sessions/session affinity in our clustered environment, but if this approach won't work, how might one go about implementing a back-end approach? My initial thoughts are to create a JDBC-backed implementation of SessionAttributeStore.
Aug 13th, 2012, 02:22 AM
SessionAttributeStore would be the way to go. Jdbc isn't great for a key-value store but if it's what you have already it makes sense.
Aug 13th, 2012, 09:43 AM
I don't think I understand. If SessionAttributeStore is the way to go, how else might I achieve the goal of storing state between the initial auth request and the code or token grant in an clustered setup if a JDBC-backed implementation of SessionAttributeStore isn't a great idea? I haven't started implementing yet, so I'm open to suggestions/directions/examples.
Aug 14th, 2012, 02:33 AM
I just mean that JDBC isn't ideally suited to key-value store implementations (the relational model on the server isn't). That shouldn't stop you from implementing it if you already use JDBC for other things. I don't want to start a debate about the best database for k-v stores. Try asking on the Spring Data forum.
Oct 17th, 2012, 02:11 PM
Just to clarify my understanding, for a clustered authorization server, if we enable sticky sessions, we don't have to worry about implementing a shared SessionAttributeStore, but we still would need to implement the shared AuthorizationCodeServices, correct?
Oct 18th, 2012, 04:25 AM
Yes, I think that's right. The token endpoint requests cannot be correlated with a user session, so authorization codes would not be either.
Tags for this Thread