clustered auth server?

[jrod]

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.

[Dave Syer]

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.

[enkhchuluun]

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.

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.

[Dave Syer]

@enkhchuluun I don't think that's right. The AuthorizationEndpoint doesn't explicitly interact with the HttpSession anywhere.

[jrod]

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.

I've implemented an instance of JdbcAuthorizationCodeServices to serve as a shared AuthorizationCodeServices for the clustered token endpoint. Is this sufficient?

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.

[Dave Syer]

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.

[jrod]

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.

[Dave Syer]

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.

[jrod]

Understood. I don't have an opinion either on which database is best; I'm just looking for a solution to the clustering problem. That being said, I'll try my hand at a JDBC-based approach and see how it goes. Thanks for your input!

[kldavis4]

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?