Session and SSO

[gkaur <gk...@vonage.com>]

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. 

Thank you
-Gurpreet
-- 
View this message in context: http://n2.nabble.com/Session-and-SSO-tp3294375p3294375.html
Sent from the Shiro User mailing list archive at Nabble.com.

Re: Session and SSO

[Les Hazlewood <lh...@apache.org>]

On Tue, Jul 21, 2009 at 8:52 AM, gkaur<gk...@vonage.com> 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').

Re: Session and SSO

[Bradley Beddoes <br...@gmail.com>]

You'd be looking at something like SAML for that functionality which
isn't supported by shiro out of the box but could be wired in.


On Fri, Jul 24, 2009 at 12:11 AM, gkaur<gk...@vonage.com> wrote:
>
> Hi
>
> Thank you for your response. I have one more question.
> We have decided to not go the route of having federated sessions among
> different applications to remember user info but instead have centralized
> authentication server. Is there something in Shiro that provides a
> centralized server...i.e somehow all the servlets even on separate boxes
> forward the request to Shiro and Shiro applies some filter on the request to
> see if the user is authenticated and send a response back to the servlet?
>
> -Gurpreet
>
>
>
> gkaur 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.
>>
>> Thank you
>> -Gurpreet
>>
>
> --
> View this message in context: http://n2.nabble.com/Session-and-SSO-tp3294375p3309807.html
> Sent from the Shiro User mailing list archive at Nabble.com.
>

Re: Session and SSO

[gkaur <gk...@vonage.com>]

Hi

Thank you for your response. I have one more question.
We have decided to not go the route of having federated sessions among
different applications to remember user info but instead have centralized
authentication server. Is there something in Shiro that provides a
centralized server...i.e somehow all the servlets even on separate boxes
forward the request to Shiro and Shiro applies some filter on the request to
see if the user is authenticated and send a response back to the servlet?

-Gurpreet



gkaur 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. 
> 
> Thank you
> -Gurpreet
> 

-- 
View this message in context: http://n2.nabble.com/Session-and-SSO-tp3294375p3309807.html
Sent from the Shiro User mailing list archive at Nabble.com.

Re: Session and SSO

[Kapil Sachdeva <ks...@gmail.com>]

Answers are inlined:

On Tue, Jul 21, 2009 at 7:52 AM, gkaur <gk...@vonage.com> 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



Shiro has two type of sessions management for web applications.

- "shiro" : This is an implementation of session management by the shiro
framework/library
- "http"  :  This is an implementation which delegates the session
management to the Servlet Container in which your application is running
i.e. to the implementation of standard java HttpSession provided by your
container/app server.

Normally web applications use "http" mode.

>> and if those servlets existed on different physical machines.

This is normally out of scope of shiro as your application is free to choose
various options for session sharing/duplication across cluster. I am not
expert in this field but I guess application servers must be providing
support to replicate the session information or you can use solutions like
terracota.


>
>
> 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.


It is my understanding that it is up to you to build SSO on top of Shiro.

Hope this helps.


>
>
> Thank you
> -Gurpreet
> --
> View this message in context:
> http://n2.nabble.com/Session-and-SSO-tp3294375p3294375.html
> Sent from the Shiro User mailing list archive at Nabble.com.
>