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

[Matt Wringe]

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.
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.
This would be enough for the wsrp ws-security, but I think the
clusteringsso filter would still need to exist.

> 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).

This is all very similar to how the clustering sso currently works, and
I would like to reuse as much code between the two.

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.

> 
> 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
> 
>