On Fri, 2011-03-25 at 22:41 +0100, Julien Viet wrote:
> the whole portal login module is not specific to JBoss actually, is it ?
its only used if clustering is enable and the
javax.security.jacc.PolicyContext class exists on the classpath. So its
only used for JBoss.
I also don't think the login method will ever do anything either since
it will only do something if the password is a rememberme password. As
far as I can tell it will never receive a rememberme password here.
Only the commit method appears to do anything, and all its doing is
adding the credentials to the session.
The PortalLoginModule only seems to exist to work with the
ClusteringSSOFilter.
>
> it would be great that you describe your changes so Alain that worked on that
subject and myself can have an overview of the changes and give our opinion.
Ok, I think I understand the issues a bit better now. We need to have a
mechanism to retrieve the actual password for wsrp ws-security and for
clustering sso. We have a few options:
1) store the actual password in the http session. This is currently
being done in the PortalLoginModule if the clustering exo.profile is
active.
1.1) this currently works for clustering sso, but would require another
profile type to activate for ws-security (since we don't want to require
clustering for ws-security to work).
Has some issues with JBoss specific code in the gatein java classes and
hardcoded profile names in java classes. But its easy to add the new
profile requirement.
or
1.2) We can clean up this code a bit better and make it less dependent
on profiles.
We can remove the PortalLoginModule class since its only used for the
ClusteringSSOFilter.
The WCILoginController already adds the credentials to the request
session and removes them in the GenericAuthentication.login method**. We
could just not remove the credentials in the GenericAuthentication.login
method.
This would leave the credentials always available in the session
regardless of the active exo.profiles.
Makes it easier to access for the ws-security case as we don't need a
new profile, still requires the ClusteringSSOFilter class for
clustering.
2) change how we handle rememberme and tokens so that we don't need to
pass the credentials as url parameters on a redirect. This should allow
us to use the actual passwords and get rid of need for the
ClusteringSSOFilter and PortalLoginModule classes. It should make it
easier to access the proper credentials in the ws-security and will make
things work in a more standard manner for clustering.
Don't know how exactly to handle this situation. We could switch to
using programmatic login, but this would require server specific code as
it wont work in the generic case (unless using servlet 3.0 containers).
Maybe have the login.jsp automatically submit the form if the username
and password are passed to it?
1.2 is probably the most realistic option at this point and requires
minimal changes. Any thoughts on this?
**: note if there is a reason why these need to be removed here, please
note that it only gets removed in the GenericAuthentication.login
method, not the servlet 3.0 server specific ones.
> On Mar 25, 2011, at 9:58 PM, Matt Wringe wrote:
>
> > On Wed, 2011-03-23 at 15:11 +0100, Julien Viet wrote:
> >>
> >>
> >> On Tue, Mar 22, 2011 at 2:47 PM, Matt Wringe <mwringe(a)redhat.com>
> >> wrote:
> >>
> >> On Tue, 2011-03-22 at 00:08 +0100, Julien Viet wrote:
> >>>
> >>>
> >>> On Mon, Mar 21, 2011 at 2:56 PM, Matt Wringe
> >> <mwringe(a)redhat.com>
> >>> wrote:
> >>> Hi,
> >>>
> >>> For wsrp ws-security we need to pass the username
> >> and actual
> >>> password
> >>> (not token) between the consumer and producer. We
> >> need to do
> >>> what is
> >>> currently done with the ClusteredSSOFilter and
> >>> PortalLoginModule when
> >>> the clustering exo.profile is enabled.
> >>>
> >>> What is the current policy for dealing with
> >> exo.profiles? I
> >>> can't seem
> >>> to find much info on it other than when to use it
> >> for the
> >>> clustering
> >>> setup.
> >>>
> >>>
> >>>
> >>> When the server boots it shows the active profiles on the
> >> console
> >>> like:
> >>>
> >>>
> >>> Mar 21, 2011 11:57:38 PM
> >> org.exoplatform.container.RootContainer
> >>> <init>
> >>> INFO: Active profiles [tomcat]
> >>>
> >>>
> >>> The server determines a profile by itself (tomcat for
> >> tomcat, etc...),
> >>> additional profiles are added with the -Dexo.profiles VM
> >> argument with
> >>> a comma separated list
> >>>
> >>>
> >>> When you want to activate a part of the configuration you
> >> have to
> >>> depend on a profile, here again you can specify a list of
> >> profile with
> >>> a comma separated list.
> >>>
> >>>
> >>> You can determine which elements of the configuration
> >> accepts a
> >>> profile by looking at
> >>> the
http://www.exoplaform.org/xml/ns/kernel_1_1.xsd schema,
> >> normally
> >>> it should answer your needs if you are going to activate
> >> some part of
> >>> the server this way.
> >>>
> >>> Would it be acceptable to create a 'sso' or
> >> 'wsrpsso' profile
> >>> which
> >>> would also enable the authenticated credentials
> >> propagation in
> >>> the
> >>> ClusteringSSOFilter and PortalLoginModule? Or is the
> >> profile
> >>> setup
> >>> reserved for other tasks?
> >>>
> >>>
> >>> This makes sense to me, although the clustered sso filter is
> >>> configured differently because it's a servlet filter, it
> >> uses
> >>> (unfortunately) programmatic hardcoded profile selection
> >> with the
> >>> code: ExoContainer.getProfiles().contains("cluster")
> >>>
> >>>
> >>> Also I would like to move this server dependent code to the
> >> WCI module
> >>> at some point (I wanted to do it currently in trunk, so this
> >> code
> >>> would move to a proper location and could be more easily
> >> tested), but
> >>> doing that would need to bring a dependency of this filter
> >> onto the
> >>> exo kernel which is something we would like to avoid.
> >> Perhaps there is
> >>> something creative than can be done, to keep flexibility and
> >> avoid the
> >>> duplication in WSRP.
> >>
> >>
> >> An option would be to change the code in wci and allow for the
> >> retrieval
> >> of the actual password when presented with the username and
> >> token.
> >>
> >>
> >> There is a notion of token store in GateIn itself, I don't know if it
> >> is related or not.
> >>
> >> If we can create a type of password store in wci, then we
> >> don't need to
> >> store the password in the servlet session during the a portal
> >> login.
> >>
> >>
> >> Somehow this already kind of exist with the token store, that stores
> >> the password for the login. It is used when someone performs a form
> >> login not triggerred by Java EE (i.e 90% of the time).
> >> This token store is used to produce a token that will be used with the
> >> browser interactions. Perhaps it would make sense to move it to WCI as
> >> well.
> >>
> >> This would be enough for the wsrp ws-security, but I think the
> >> clusteringsso filter would still need to exist.
> >>
> >>
> >> My concern was about moving this server specific part to the JBoss AS
> >> WCI SPI implementation.
> >>
> >>
> >>> Actually I don't know exactly how you plan to use it in
> >> WSRP, would it
> >>> be on producer side in the producer war file ?
> >>
> >>
> >> Its not on the producer side, its on the consumer side. It
> >> basically
> >> works like this:
> >> - a user logs into the consumer portal
> >> - a user goes to access a remote portlet
> >> - the users credentials are sent from the consumer to the
> >> producer
> >> - the producer authenticates and verifies the credentials and
> >> use that
> >> to make any role based decisions.
> >>
> >> The issue is with retrieving the actual password in the
> >> consumer and not
> >> a password token (since the wci token is only valid for the
> >> original
> >> server).
> >>
> >>
> >> So the consumer would use the TokenStore to retrieve the user password
> >> to propagate it once a user has established authentication ?
> >>
> >>
> >> This is all very similar to how the clustering sso currently
> >> works, and
> >> I would like to reuse as much code between the two.
> >>
> >>
> >> Could you also check the TokenStore ? the TransientTokenStore, I think
> >> it is removed from GateIn trunk, but before Alain's work it was doing
> >> something similar.
> >>
> >>
> >> Using the current implementation if we enable the clustering
> >> profile (or
> >> create another profile which only handles the password part
> >> and not full
> >> clustering) then we can retrieve the actual password in the
> >> consumer in
> >> the same manner as the clustering setup.
> >>
> >>
> >> I understand that.
> >>
> >>
> >> The TransientTokenStore worked this way when a user performs a
> >> programmatic login:
> >>
> >>
> >> 1/ store username/password in store and get a token
> >> 2/ perform java EE authent with username and password = token
> >> 3/ during password check, if password is a token, take the real
> >> password from the token store and remove the useless token, now the
> >> password is the real password
> >> 4/ proceed to authent
> >>
> >>
> >> this would be similar, except that the token would not be removed from
> >> the token store until the user logs out.
> >
> > ok, so if the user never clicks on the logout link, then this store
> > would be a memory leak? Or do we automatically preform a logout after a
> > specific amount of time?
> >
> > I think its probably easiest to move the PortalLoginModule to the WCI
> > JBoss5/6 module and configure it to always add the real credentials to
> > the requests session regardless if the clustering profile is set or not.
> > I don't want code in wci referencing exo profiles.
> >
> > If adding it to WCI is fine, I will commit my changes and release a new
> > beta for it.
> >
> >>
> >>>
> >>> Also this code could be stay in GateIn but in a JBoss
> >> specific module
> >>> instead. My concern is that any activation of the cluster
> >> code in
> >>> tomcat could lead to a class not found exception of
> >>> the org.jboss.web.tomcat.security.login.WebAuthentication
> >> class. But
> >>> this is a different concern than the one you are expressing
> >> here of
> >>> course.
> >>>
> >>>
> >>> I would rather not have to duplicate this effort in
> >> the wsrp
> >>> code.
> >>>
> >>> Thanks,
> >>>
> >>> Matt Wringe
> >>>
> >>> _______________________________________________
> >>> gatein-dev mailing list
> >>> gatein-dev(a)lists.jboss.org
> >>>
https://lists.jboss.org/mailman/listinfo/gatein-dev
> >>>
> >>>
> >>
> >>
> >>
> >>
> >
> >
>