[gatein-dev] clustering sso, exo.profiles and wsrp webservice security
Matt Wringe
mwringe at redhat.com
Fri Mar 25 16:58:00 EDT 2011
On Wed, 2011-03-23 at 15:11 +0100, Julien Viet wrote:
>
>
> 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.
ok, so if the user never clicks on the logout link, then this store
would be a memory leak? Or do we automatically preform a logout after a
specific amount of time?
I think its probably easiest to move the PortalLoginModule to the WCI
JBoss5/6 module and configure it to always add the real credentials to
the requests session regardless if the clustering profile is set or not.
I don't want code in wci referencing exo profiles.
If adding it to WCI is fine, I will commit my changes and release a new
beta for it.
>
> >
> > 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
> >
> >
>
>
>
>
More information about the gatein-dev
mailing list