On Tue, Jul 21, 2009 at 8:52 AM, gkaur<[email protected]> wrote: > > Hi, > > I just recently started using Shiro and had a question, how is session > management implemented in Shiro, i.e how is session information remembered > between various servlets and if those servlets existed on different physical > machines. > > Also does SSO concept currently exist in Shiro? I did read some posts > regarding federated sessions but the posts aren't clear as to if this > currently exist.
If you use Shiro's native sessions, you can achieve SSO by using an enterprise caching framework. The Shiro SessionManager implementations delegate persistence/lookup operations to a SessionDAO implementation. If you provide an implementation that uses an enterprise distributed cache (as is highly recommended), you can achieve SSO very easily. So for example, if you had a TerracottaSessionDAO or GigaSpacesSessionDAO or CoherenceSessionDAO, etc, this would work. Then each application has a Shiro SecurityManager injected with this DAO implementation and then they can all 'see' the same Sessions. Shiro stores authentication state by default in the Session, so any application that has access to your cluster-specific SessionDAO can access and update the same session. The sessionId needs to be shared across all applications (think of this as the SSO Token) so they can lookup the corresponding Session from the cache. This is what is meant by 'federated' sessions - each application can access the same session if necessary, and because authentication state is stored in the Session, then implicitly you have achieved Single Sign On. This is also very useful for enterprise applications that don't participate in SSO - by using the enterprise cache to back your SessionDAO implementation, you guarantee that if any application instance in your cluster dies, any other can obtain the session. No need for server affinity (aka 'sticky sessions').
