You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@isis.apache.org by GESCONSULTOR - Óscar Bou <o....@gesconsultor.com> on 2013/08/26 16:45:16 UTC
Isis session and transaction management on a custom viewer
Hi, Dan.
As I explained on previous emails, we have a "custom viewer" made over Wavemaker technology [1], that we have adapted to Apache Isis (close source, but if anybody is interested on creating an open one, we would share the specific code needed). That allows our users to have a development studio on the web for customizing the User Interface, etc.
The point is that we looked at a given moment at the Wicket viewer code for determining how the Isis session and transaction management was done (it's stateful), but we are experiencing some problems and needs to be rebuilt.
We've also see that a recent commit has been made for the session management on the Restful Objects viewer, which is stateless.
I'm sure there are going to be more people interested on knowing how to integrate an Apache Isis domain with their own web applications based on Java (directly, not through the Restful Objects API as been made with the Javascript or Android viewers).
All our interaction with the Apache Isis domain entities is made:
- through a "custom-made" IsisDomainRepository, which contains "generic" finders (by tenant, etc.).
- through a "custom-made" infrastructure layer that interacts with Apache Isis ObjectAdapters, etc. for invoking actions.
So, at first, we are capable of working with the domain without a reference to the user's context (stateless).
So, prior to advance in one direction or another, we have some questions about current design:
1.- Stateful (Wicket) vs Stateless (RestFul Objects): why the Wicket viewer needs to hold the state, from an Apache Isis perspective? Just to hold the current user "context information"? Why to choose for other webapps integrating with Isis the stateful design, instead of the - more scalable - stateless design?
2.- Is there any class we can inherit from for stateless or stateful clients, that will be maintained in the future, as Apache Isis evolve, that takes care of web session handling, security (shiro) session, transaction management, etc. ? Perhaps we can inherit from classes currently existing on the Wicket viewer (or the Restful Objects viewer).
3.- Is there any other point we must take into account with this approach - the "custom viewer" interacting with the Apache Isis domain - ?
Thanks,
Oscar
[1] http://www.wavemaker.com
Re: Isis session and transaction management on a custom viewer
Posted by GESCONSULTOR - Óscar Bou <o....@gesconsultor.com>.
Thanks for the detailed explanation and the links to those resources.
As we currently have an Apache Isis integration with our viewer, we knew the "high-level" structure, but it needs to be improved (experiencing some session or transaction management problems that originated the request).
We are interfacing Isis only through "generic" repositories (responsible of generating screens, etc.) and a generic action execution service (that finds the proper Object Specification, etc.). We are obtaining the proper choices, default values, hidden state, (not auto-complete by now; at most in 2 weeks), etc.
With the provided information we expect to being able to solve those session handling problems.
We will look at them in detail, and come here if any doubt is raised.
Thanks again,
Oscar
El 05/09/2013, a las 15:52, Dan Haywood <da...@haywood-associates.co.uk> escribió:
> Hi Oscar,
> apols for the delay in replying on this; within...
>
> And, I'm cc'ing this to dev@i.a.o; I think it belongs there better.
>
> Dan
>
> On 26 August 2013 15:45, GESCONSULTOR - Óscar Bou <o....@gesconsultor.com>wrote:
>
>> [snip]
>> ... we have some questions about current design:
>>
>> 1.- Stateful (Wicket) vs Stateless (RestFul Objects): why the Wicket
>> viewer needs to hold the state,
>
>
> The Apache Wicket framework is stateful, that's just the way it is. In
> fact, it's one of the principles of the framework to handle this [2]. One
> needs to be aware of this [3].
>
>
>> from an Apache Isis perspective? Just to hold the current user "context
>> information"?
>
>
> No, more than this. Every component (widget) in the page is backed by a
> Wicket model (LoadableDetachableModel); these must be serializable because
> they are stored in the session. Isis entities are not serializable (nor
> would we want them to be), but the OIDs are (eg "TODO|123"). Isis handles
> this by providing mementos (for entity, property, collection, action,
> parameter). Thus, EntityModel is a Wicket model that wraps an
> ObjectAdapterMemento.
>
> But, yes, Isis itself does also have a session which represents the current
> user. This is its
> org.apache.isis.core.commons.authentication.AuthenticationSession. Isis
> delegates to Wicket to store this for it in the HttpSession; this is done
> through org.apache.isis.viewer.wicket.viewer.integration.wicket.AuthenticatedWebSessionForIsis
> (IsisWicketApplication#getWebSessionClass). By this, Wicket keeps track of
> the user making the request.
>
> 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].
>
>
>
>
>> Why to choose for other webapps integrating with Isis the stateful design,
>> instead of the - more scalable - stateless design?
>>
>>
> Umm. As [3] says, Wicket's reliance on session management means it
> wouldn't be suitable for an Amazon scale website. But I believe it's an
> appropriate technology for a typical enterprise app (that might use a farm
> of clustered servers for big deployments).
>
> Restful Objects in contrast is deliberately stateful. There is still the
> user identity issue to contend with, but that's pluggable. I hope that
> someone (who knows more about this than me) might help work through an
> oauth or equivalent implementation. My understanding (I'm by no means a
> security expert on this) is that these solutions are scalable because the
> user credentials ultimately are stored in HTTP headers (encrypted suitably,
> of course, according to the oauth protocols etc etc).
>
>
>
>> 2.- Is there any class we can inherit from for stateless or stateful
>> clients, that will be maintained in the future, as Apache Isis evolve, that
>> takes care of web session handling, security (shiro) session, transaction
>> management, etc. ? Perhaps we can inherit from classes currently existing
>> on the Wicket viewer (or the Restful Objects viewer).
>>
>
> Look at the classes above as a start point, see if you can untangle them.
>
> There is a ticket to better integrate Shiro and Wicket [6]. Right now we
> logout of the Wicket viewer by invalidating Wicket's authentication
> session. However, Shiro doesn't know about this, so it preserves its
> sessions. We do (seemingly) still get the behaviour we want, but
> improvements could be made here.
>
>
>
>
>>
>> 3.- Is there any other point we must take into account with this approach
>> - the "custom viewer" interacting with the Apache Isis domain - ?
>>
>>
> The biggest immediate risk is that you get the scoping wrong. There is a
> reasonably clear separation of scopes; see ApplicationScopedComponent,
> SessionScopedComponent, TransactionalScopedComponent. There's an old
> diagram I did [7] which shows this (it might be a bit out of date, but
> shows the general pattern).
>
> The biggest ongoing risk is that - because the API is not formally
> documented - that we change the code and break the custom viewer.
>
>
> While I can see the value of there being a formal "in-process" API, I do
> hope that most will use the RO viewer. I guess one could use the RO applib
> and RO viewer on the same box as a loopback; not sure if that would add to
> much overhead to be feasible.
>
> HTH
> Dan
>
>
>
>
>>
>>
>> Thanks,
>>
>> Oscar
>>
>>
>> [1] http://www.wavemaker.com
>>
>>
>
> [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
Re: Isis session and transaction management on a custom viewer
Posted by GESCONSULTOR - Óscar Bou <o....@gesconsultor.com>.
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 <da...@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 <da...@yahoo.co.nz>
> To: "users@isis.apache.org" <us...@isis.apache.org>
> Cc: dev <de...@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....@gesconsultor.com>
> To: users@isis.apache.org; David Tildesley <da...@yahoo.co.nz>
> Cc: dev <de...@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 <da...@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
Re: Isis session and transaction management on a custom viewer
Posted by GESCONSULTOR - Óscar Bou <o....@gesconsultor.com>.
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 <da...@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 <da...@yahoo.co.nz>
> To: "users@isis.apache.org" <us...@isis.apache.org>
> Cc: dev <de...@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....@gesconsultor.com>
> To: users@isis.apache.org; David Tildesley <da...@yahoo.co.nz>
> Cc: dev <de...@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 <da...@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
Re: Isis session and transaction management on a custom viewer
Posted by David Tildesley <da...@yahoo.co.nz>.
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 <da...@yahoo.co.nz>
To: "users@isis.apache.org" <us...@isis.apache.org>
Cc: dev <de...@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....@gesconsultor.com>
To: users@isis.apache.org; David Tildesley <da...@yahoo.co.nz>
Cc: dev <de...@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 <da...@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
Re: Isis session and transaction management on a custom viewer
Posted by David Tildesley <da...@yahoo.co.nz>.
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 <da...@yahoo.co.nz>
To: "users@isis.apache.org" <us...@isis.apache.org>
Cc: dev <de...@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....@gesconsultor.com>
To: users@isis.apache.org; David Tildesley <da...@yahoo.co.nz>
Cc: dev <de...@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 <da...@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
Re: Isis session and transaction management on a custom viewer
Posted by David Tildesley <da...@yahoo.co.nz>.
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. 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.
Cheers,
David.
________________________________
From: GESCONSULTOR - Óscar Bou <o....@gesconsultor.com>
To: users@isis.apache.org; David Tildesley <da...@yahoo.co.nz>
Cc: dev <de...@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 <da...@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
Re: Isis session and transaction management on a custom viewer
Posted by David Tildesley <da...@yahoo.co.nz>.
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. 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.
Cheers,
David.
________________________________
From: GESCONSULTOR - Óscar Bou <o....@gesconsultor.com>
To: users@isis.apache.org; David Tildesley <da...@yahoo.co.nz>
Cc: dev <de...@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 <da...@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
Re: Isis session and transaction management on a custom viewer
Posted by GESCONSULTOR - Óscar Bou <o....@gesconsultor.com>.
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 <da...@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
Re: Isis session and transaction management on a custom viewer
Posted by GESCONSULTOR - Óscar Bou <o....@gesconsultor.com>.
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 <da...@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
Re: Isis session and transaction management on a custom viewer
Posted by David Tildesley <da...@yahoo.co.nz>.
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
Re: Isis session and transaction management on a custom viewer
Posted by GESCONSULTOR - Óscar Bou <o....@gesconsultor.com>.
Thanks for the detailed explanation and the links to those resources.
As we currently have an Apache Isis integration with our viewer, we knew the "high-level" structure, but it needs to be improved (experiencing some session or transaction management problems that originated the request).
We are interfacing Isis only through "generic" repositories (responsible of generating screens, etc.) and a generic action execution service (that finds the proper Object Specification, etc.). We are obtaining the proper choices, default values, hidden state, (not auto-complete by now; at most in 2 weeks), etc.
With the provided information we expect to being able to solve those session handling problems.
We will look at them in detail, and come here if any doubt is raised.
Thanks again,
Oscar
El 05/09/2013, a las 15:52, Dan Haywood <da...@haywood-associates.co.uk> escribió:
> Hi Oscar,
> apols for the delay in replying on this; within...
>
> And, I'm cc'ing this to dev@i.a.o; I think it belongs there better.
>
> Dan
>
> On 26 August 2013 15:45, GESCONSULTOR - Óscar Bou <o....@gesconsultor.com>wrote:
>
>> [snip]
>> ... we have some questions about current design:
>>
>> 1.- Stateful (Wicket) vs Stateless (RestFul Objects): why the Wicket
>> viewer needs to hold the state,
>
>
> The Apache Wicket framework is stateful, that's just the way it is. In
> fact, it's one of the principles of the framework to handle this [2]. One
> needs to be aware of this [3].
>
>
>> from an Apache Isis perspective? Just to hold the current user "context
>> information"?
>
>
> No, more than this. Every component (widget) in the page is backed by a
> Wicket model (LoadableDetachableModel); these must be serializable because
> they are stored in the session. Isis entities are not serializable (nor
> would we want them to be), but the OIDs are (eg "TODO|123"). Isis handles
> this by providing mementos (for entity, property, collection, action,
> parameter). Thus, EntityModel is a Wicket model that wraps an
> ObjectAdapterMemento.
>
> But, yes, Isis itself does also have a session which represents the current
> user. This is its
> org.apache.isis.core.commons.authentication.AuthenticationSession. Isis
> delegates to Wicket to store this for it in the HttpSession; this is done
> through org.apache.isis.viewer.wicket.viewer.integration.wicket.AuthenticatedWebSessionForIsis
> (IsisWicketApplication#getWebSessionClass). By this, Wicket keeps track of
> the user making the request.
>
> 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].
>
>
>
>
>> Why to choose for other webapps integrating with Isis the stateful design,
>> instead of the - more scalable - stateless design?
>>
>>
> Umm. As [3] says, Wicket's reliance on session management means it
> wouldn't be suitable for an Amazon scale website. But I believe it's an
> appropriate technology for a typical enterprise app (that might use a farm
> of clustered servers for big deployments).
>
> Restful Objects in contrast is deliberately stateful. There is still the
> user identity issue to contend with, but that's pluggable. I hope that
> someone (who knows more about this than me) might help work through an
> oauth or equivalent implementation. My understanding (I'm by no means a
> security expert on this) is that these solutions are scalable because the
> user credentials ultimately are stored in HTTP headers (encrypted suitably,
> of course, according to the oauth protocols etc etc).
>
>
>
>> 2.- Is there any class we can inherit from for stateless or stateful
>> clients, that will be maintained in the future, as Apache Isis evolve, that
>> takes care of web session handling, security (shiro) session, transaction
>> management, etc. ? Perhaps we can inherit from classes currently existing
>> on the Wicket viewer (or the Restful Objects viewer).
>>
>
> Look at the classes above as a start point, see if you can untangle them.
>
> There is a ticket to better integrate Shiro and Wicket [6]. Right now we
> logout of the Wicket viewer by invalidating Wicket's authentication
> session. However, Shiro doesn't know about this, so it preserves its
> sessions. We do (seemingly) still get the behaviour we want, but
> improvements could be made here.
>
>
>
>
>>
>> 3.- Is there any other point we must take into account with this approach
>> - the "custom viewer" interacting with the Apache Isis domain - ?
>>
>>
> The biggest immediate risk is that you get the scoping wrong. There is a
> reasonably clear separation of scopes; see ApplicationScopedComponent,
> SessionScopedComponent, TransactionalScopedComponent. There's an old
> diagram I did [7] which shows this (it might be a bit out of date, but
> shows the general pattern).
>
> The biggest ongoing risk is that - because the API is not formally
> documented - that we change the code and break the custom viewer.
>
>
> While I can see the value of there being a formal "in-process" API, I do
> hope that most will use the RO viewer. I guess one could use the RO applib
> and RO viewer on the same box as a loopback; not sure if that would add to
> much overhead to be feasible.
>
> HTH
> Dan
>
>
>
>
>>
>>
>> Thanks,
>>
>> Oscar
>>
>>
>> [1] http://www.wavemaker.com
>>
>>
>
> [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
Re: Isis session and transaction management on a custom viewer
Posted by David Tildesley <da...@yahoo.co.nz>.
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
Re: Isis session and transaction management on a custom viewer
Posted by Dan Haywood <da...@haywood-associates.co.uk>.
Hi Oscar,
apols for the delay in replying on this; within...
And, I'm cc'ing this to dev@i.a.o; I think it belongs there better.
Dan
On 26 August 2013 15:45, GESCONSULTOR - Óscar Bou <o....@gesconsultor.com>wrote:
> [snip]
> ... we have some questions about current design:
>
> 1.- Stateful (Wicket) vs Stateless (RestFul Objects): why the Wicket
> viewer needs to hold the state,
The Apache Wicket framework is stateful, that's just the way it is. In
fact, it's one of the principles of the framework to handle this [2]. One
needs to be aware of this [3].
> from an Apache Isis perspective? Just to hold the current user "context
> information"?
No, more than this. Every component (widget) in the page is backed by a
Wicket model (LoadableDetachableModel); these must be serializable because
they are stored in the session. Isis entities are not serializable (nor
would we want them to be), but the OIDs are (eg "TODO|123"). Isis handles
this by providing mementos (for entity, property, collection, action,
parameter). Thus, EntityModel is a Wicket model that wraps an
ObjectAdapterMemento.
But, yes, Isis itself does also have a session which represents the current
user. This is its
org.apache.isis.core.commons.authentication.AuthenticationSession. Isis
delegates to Wicket to store this for it in the HttpSession; this is done
through org.apache.isis.viewer.wicket.viewer.integration.wicket.AuthenticatedWebSessionForIsis
(IsisWicketApplication#getWebSessionClass). By this, Wicket keeps track of
the user making the request.
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].
> Why to choose for other webapps integrating with Isis the stateful design,
> instead of the - more scalable - stateless design?
>
>
Umm. As [3] says, Wicket's reliance on session management means it
wouldn't be suitable for an Amazon scale website. But I believe it's an
appropriate technology for a typical enterprise app (that might use a farm
of clustered servers for big deployments).
Restful Objects in contrast is deliberately stateful. There is still the
user identity issue to contend with, but that's pluggable. I hope that
someone (who knows more about this than me) might help work through an
oauth or equivalent implementation. My understanding (I'm by no means a
security expert on this) is that these solutions are scalable because the
user credentials ultimately are stored in HTTP headers (encrypted suitably,
of course, according to the oauth protocols etc etc).
> 2.- Is there any class we can inherit from for stateless or stateful
> clients, that will be maintained in the future, as Apache Isis evolve, that
> takes care of web session handling, security (shiro) session, transaction
> management, etc. ? Perhaps we can inherit from classes currently existing
> on the Wicket viewer (or the Restful Objects viewer).
>
Look at the classes above as a start point, see if you can untangle them.
There is a ticket to better integrate Shiro and Wicket [6]. Right now we
logout of the Wicket viewer by invalidating Wicket's authentication
session. However, Shiro doesn't know about this, so it preserves its
sessions. We do (seemingly) still get the behaviour we want, but
improvements could be made here.
>
> 3.- Is there any other point we must take into account with this approach
> - the "custom viewer" interacting with the Apache Isis domain - ?
>
>
The biggest immediate risk is that you get the scoping wrong. There is a
reasonably clear separation of scopes; see ApplicationScopedComponent,
SessionScopedComponent, TransactionalScopedComponent. There's an old
diagram I did [7] which shows this (it might be a bit out of date, but
shows the general pattern).
The biggest ongoing risk is that - because the API is not formally
documented - that we change the code and break the custom viewer.
While I can see the value of there being a formal "in-process" API, I do
hope that most will use the RO viewer. I guess one could use the RO applib
and RO viewer on the same box as a loopback; not sure if that would add to
much overhead to be feasible.
HTH
Dan
>
>
> Thanks,
>
> Oscar
>
>
> [1] http://www.wavemaker.com
>
>
[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
Re: Isis session and transaction management on a custom viewer
Posted by Dan Haywood <da...@haywood-associates.co.uk>.
Hi Oscar,
apols for the delay in replying on this; within...
And, I'm cc'ing this to dev@i.a.o; I think it belongs there better.
Dan
On 26 August 2013 15:45, GESCONSULTOR - Óscar Bou <o....@gesconsultor.com>wrote:
> [snip]
> ... we have some questions about current design:
>
> 1.- Stateful (Wicket) vs Stateless (RestFul Objects): why the Wicket
> viewer needs to hold the state,
The Apache Wicket framework is stateful, that's just the way it is. In
fact, it's one of the principles of the framework to handle this [2]. One
needs to be aware of this [3].
> from an Apache Isis perspective? Just to hold the current user "context
> information"?
No, more than this. Every component (widget) in the page is backed by a
Wicket model (LoadableDetachableModel); these must be serializable because
they are stored in the session. Isis entities are not serializable (nor
would we want them to be), but the OIDs are (eg "TODO|123"). Isis handles
this by providing mementos (for entity, property, collection, action,
parameter). Thus, EntityModel is a Wicket model that wraps an
ObjectAdapterMemento.
But, yes, Isis itself does also have a session which represents the current
user. This is its
org.apache.isis.core.commons.authentication.AuthenticationSession. Isis
delegates to Wicket to store this for it in the HttpSession; this is done
through org.apache.isis.viewer.wicket.viewer.integration.wicket.AuthenticatedWebSessionForIsis
(IsisWicketApplication#getWebSessionClass). By this, Wicket keeps track of
the user making the request.
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].
> Why to choose for other webapps integrating with Isis the stateful design,
> instead of the - more scalable - stateless design?
>
>
Umm. As [3] says, Wicket's reliance on session management means it
wouldn't be suitable for an Amazon scale website. But I believe it's an
appropriate technology for a typical enterprise app (that might use a farm
of clustered servers for big deployments).
Restful Objects in contrast is deliberately stateful. There is still the
user identity issue to contend with, but that's pluggable. I hope that
someone (who knows more about this than me) might help work through an
oauth or equivalent implementation. My understanding (I'm by no means a
security expert on this) is that these solutions are scalable because the
user credentials ultimately are stored in HTTP headers (encrypted suitably,
of course, according to the oauth protocols etc etc).
> 2.- Is there any class we can inherit from for stateless or stateful
> clients, that will be maintained in the future, as Apache Isis evolve, that
> takes care of web session handling, security (shiro) session, transaction
> management, etc. ? Perhaps we can inherit from classes currently existing
> on the Wicket viewer (or the Restful Objects viewer).
>
Look at the classes above as a start point, see if you can untangle them.
There is a ticket to better integrate Shiro and Wicket [6]. Right now we
logout of the Wicket viewer by invalidating Wicket's authentication
session. However, Shiro doesn't know about this, so it preserves its
sessions. We do (seemingly) still get the behaviour we want, but
improvements could be made here.
>
> 3.- Is there any other point we must take into account with this approach
> - the "custom viewer" interacting with the Apache Isis domain - ?
>
>
The biggest immediate risk is that you get the scoping wrong. There is a
reasonably clear separation of scopes; see ApplicationScopedComponent,
SessionScopedComponent, TransactionalScopedComponent. There's an old
diagram I did [7] which shows this (it might be a bit out of date, but
shows the general pattern).
The biggest ongoing risk is that - because the API is not formally
documented - that we change the code and break the custom viewer.
While I can see the value of there being a formal "in-process" API, I do
hope that most will use the RO viewer. I guess one could use the RO applib
and RO viewer on the same box as a loopback; not sure if that would add to
much overhead to be feasible.
HTH
Dan
>
>
> Thanks,
>
> Oscar
>
>
> [1] http://www.wavemaker.com
>
>
[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