On Tue, Mar 22, 2011 at 2:47 PM, Matt Wringe <mwringe@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@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@lists.jboss.org
>         https://lists.jboss.org/mailman/listinfo/gatein-dev
>
>