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

[Julien Viet]

the goal of the token is to avoid to send the password in clear on the networkd during the http redirect performed by the remember me to trigger java ee authentication by the servlet container.

On Mar 25, 2011, at 9:58 PM, Matt Wringe wrote:

> On Wed, 2011-03-23 at 16:35 +0100, Boleslaw Dawidowicz wrote:
>> On Mar 23, 2011, at 3:11 PM, Julien Viet wrote:
>> 
>>> 
>>> 
>>> 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.
>>> 
>> 
>> Just to add some context ClusteredSSOFilter was brought in as a quick workaround because token service breaks the way auth is propagated around the cluster in JBoss AS. SSO Valve that does the job was propagating token instead of password and IIRC token service store content was not replicated between nodes anyhow.
>> 
>> But this is something that users may also hit when trying to plug their LoginModule into portal JAAS stack. I saw people removing the whole LM stack and putting forked pieces of GTN auth code from different modules into new LM to workaround this. We could try to make it more friendly for customizations and implement rememberme/token feature in a different way - just a thought - I don't have any ready design inside of my heat atm. 
> 
> The rememberme feature is separate from the security tokens (they are
> similar in implementation though). We are using the tokens instead of
> the actual passwords for security reasons, but I am not sure why
> exactly. It does seem a bit strange the way are are doing it especially
> since it does break things like Tomcat SSO.
> 
> Can someone explain why we need to use tokens instead of just using the
> actual password?
>