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
