> The only back end ticket storage I implemented that is sharable across nodes > is the CouchDB implementation. I have theorized that you could use something > like "BigCouch" to scale up the application state in this case.
I bet you could. I don’t think it needs to be normative because entities (virtually always) only issue tickets for themselves to validate. I was thinking that you could just embed some node identifier in the ticket string as you hand it to the client and an HTTP-based load balancer could look at the ticket coming back from a service and farm the request out. There would be many other ways to do it, though, as you mention. The difference here is small until the size of the deployment gets very, very, very large. That's enough for me to say "personal preference”, but there are others who have very strong preferences about any server-side session state that needs to be shared between nodes. I really want to understand why OAuth 2.0 went for back-channel queries rather than signed messages. If anyone knows the rationale there, I would be fascinated. I would have thought the opposite given the limitations that using TLS for trust imposes, but obviously, I don’t know what the problems really look like at that scale. -- You received this message because you are subscribed to the Google Groups "CAS Community" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. Visit this group at https://groups.google.com/a/apereo.org/group/cas-user/.
