8:47 a.m.
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.
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(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/gatein-dev