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?