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

[Julien Viet]

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

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/20110322/a0238c5e/attachment.html