isis-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From GESCONSULTOR - Óscar Bou <o....@gesconsultor.com>
Subject Re: Isis session and transaction management on a custom viewer
Date Sat, 07 Sep 2013 07:53:48 GMT

Thanks a lot, David.

Yes, we have other platforms integrated with CAS, so the session could be kept alive longer
than the Isis web session, so that could potentially occur.

If I've understood well, you have enabled the Shiro Native Session as per [1], isn't it ?

With CAS the "remember me" feature is managed by the CAS Server, and also the SSO session
time out ([2]), so in this case the native session manager seems not to be needed (nor compatible),
but it could be the default configuration for Apache Isis webapps, with the advantages you
pointed out.

Just to point others interested on CAS and Shiro, there's a really simple demo project right
here [3].


Thanks again for sharing your conclusions when figured out.


Regards,

Oscar


[1] http://shiro.apache.org/web.html
[2] https://wiki.jasig.org/display/CASUM/HOWTO+Configure+Single+Sign+On+Session+Timeout
[3] https://github.com/leleuj/cas-shiro-demo


El 06/09/2013, a las 23:42, David Tildesley <davotnz@yahoo.co.nz> escribió:

> Hi Oscar,
> 
> David (me) wrote:
> 
>> I guess if you don't have desktop (kerberos)  SSO to the CAS sts then you haven't
got the same issue as us if you keep the cas token timeout less than the http session timeout.
> 
> Scrub that previous assumption - you will have the same problem if the user is accessing
other services and therefore keeping the CAS SSO token "alive" - they will arrive back at
the application with the http session expired but with a valid CAS token and Shiro will dutifully
authenticate them and pass them to a resource with a brand new session - same potential for
a bad user experience. Our solution (when we figure it all out) should work for your scenarios
also.
> 
> David.
> 
> 
> ________________________________
> From: David Tildesley <davotnz@yahoo.co.nz>
> To: "users@isis.apache.org" <users@isis.apache.org> 
> Cc: dev <dev@isis.apache.org> 
> Sent: Saturday, 7 September 2013 9:37 AM
> Subject: Re: Isis session and transaction management on a custom viewer
> 
> 
> Hi Oscar,
> 
> That's good (CAS) where Shiro has a plugin. We (it's not my money) weren't prepared to
invest in writing a Kerberos authentication plugin for Shiro when Weblogic already does Kerberos
authentication and it's already got the tick from Ent architecture.
> 
> I'll let you know what conclusions we come to on the session timeout and "logout" - it's
all about giving the user a good experience as SSO can confuse them when it seamlessly logs
them back in but they get a different session. 
> 
> Cheers,
> David.
> 
> 
> ________________________________
> From: GESCONSULTOR - Óscar Bou <o.bou@gesconsultor.com>
> To: users@isis.apache.org; David Tildesley <davotnz@yahoo.co.nz> 
> Cc: dev <dev@isis.apache.org> 
> Sent: Saturday, 7 September 2013 3:17 AM
> Subject: Re: Isis session and transaction management on a custom viewer
> 
> 
> Hi, David.
> 
> Really interesting. This second  we plan to integrate with the CAS SSO platform the Isis
domain, as detailed in [1]. 
> 
> Authentication in CAS, authorization in Domain, thanks to Shiro (and also on CAS on ).

> 
> It would be helpful to know about your approach to logout and session timeout when you
implement it. But in our case seems that CAS will manage that functionality, instead of Shiro.
> 
> Thanks,
> 
> Oscar
> 
> 
> 
> [1] http://shiro.apache.org/cas.html
> 
> El 06/09/2013, a las 12:52, David Tildesley <davotnz@yahoo.co.nz> escribió:
> 
>> Hi Dan,
>> 
>> Dan wrote:
>> 
>>> If using Isis' Shiro integration for authenticaiotn/authorizatino, then
>>> there are also Shiros session management to consider [4].  I am pretty sure
>>> the default for that is also HttpSession, but it would seem to be pluggable
>>> and they say it supports clusters [5].
>> 
>> You're right. Played with this by co-incidence today. I think this default causes
some loss of useful Shiro features (deferring to the container). Turned on Shiro "native session
manager" today by simple property in Shiro.ini as per Shiro documentation[4]. Works ok and
adds more capability (e.g. ability to define Shiro session event listener,define Shiro session
timeout, ...). We are leaning towards form based container based authentication (already hooked
Shiro into trusting container authentication and leaving Shiro to do authorisation). Reason
is that we are using container authentication for "NegotiateAssertion" for enterprise desktop
SSO (Kerberos) and we make this a "permanent feature" and also  have a fall through ("SUFFICIENT")
 AD ldap authenticator defined as next container authentication provider - simply to make
life easy for the testers. We hope to log events off the Shiro session events (start, stop,
...) . But we've still got work to do
>> around this and the side affects (e.g. session timeout and "logout" behaviour). 
>> 
>> If  using native session manager then need to name the Shiro session cookie something
other than the default JSESSIONID because it causes weirdness when the container also produces
a session cookie of the same name.
>> 
>> David.
>> 
>> 
>> [2] http://wicket.apache.org/meet/introduction.html
>> [3] http://www.jtict.com/blog/wicket-isnt-suited-for-websites/
>> [4] http://shiro.apache.org/session-management.html
>> [5] http://shiro.apache.org/web.html#Web-ServletContainerSessions
>> [6] https://issues.apache.org/jira/browse/ISIS-299
>> [7]
>> https://github.com/apache/isis/blob/master/core/src/docbkx/guide-runtime-to-incorporate/images/architecture.png


Mime
View raw message