[gatein-dev] clustering sso, exo.profiles and wsrp webservice security

Wed Mar 23 10:11:59 EDT 2011

On Tue, Mar 22, 2011 at 2:47 PM, Matt Wringe <mwringe at 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 at 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.

>
> >
> > 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 at lists.jboss.org
> >         https://lists.jboss.org/mailman/listinfo/gatein-dev
> >
> >
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/gatein-dev/attachments/20110323/572bcd17/attachment.html 