8:56 a.m.
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.
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?
I would rather not have to duplicate this effort in the wsrp code.
Thanks,
Matt Wringe
6:08 p.m.
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. 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(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/gatein-dev
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
9:11 a.m.
On Tue, Mar 22, 2011 at 2:47 PM, Matt Wringe <mwringe(a)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(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.
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.
>
> 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
>
>
10:35 a.m.
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.
Bolek
3:58 p.m.
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?
4:39 p.m.
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?
3:58 p.m.
On Wed, 2011-03-23 at 15:11 +0100, Julien Viet wrote:
On Tue, Mar 22, 2011 at 2:47 PM, Matt Wringe <mwringe(a)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(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.
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(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/gatein-dev
>
>
4:41 p.m.
the whole portal login module is not specific to JBoss actually, is it ?
it would be great that you describe your changes so Alain that worked on that subject and
myself can have an overview of the changes and give our opinion.
On Mar 25, 2011, at 9:58 PM, Matt Wringe wrote:
On Wed, 2011-03-23 at 15:11 +0100, Julien Viet wrote:
>
>
> On Tue, Mar 22, 2011 at 2:47 PM, Matt Wringe <mwringe(a)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(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.
>
>
> 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(a)lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/gatein-dev
>>
>>
>
>
>
>
4:53 p.m.
On Fri, 2011-03-25 at 22:41 +0100, Julien Viet wrote:
the whole portal login module is not specific to JBoss actually, is
it ?
its only used if clustering is enable and the
javax.security.jacc.PolicyContext class exists on the classpath. So its
only used for JBoss.
I also don't think the login method will ever do anything either since
it will only do something if the password is a rememberme password. As
far as I can tell it will never receive a rememberme password here.
Only the commit method appears to do anything, and all its doing is
adding the credentials to the session.
The PortalLoginModule only seems to exist to work with the
ClusteringSSOFilter.
it would be great that you describe your changes so Alain that worked on that subject and
myself can have an overview of the changes and give our opinion.
On Mar 25, 2011, at 9:58 PM, Matt Wringe wrote:
> On Wed, 2011-03-23 at 15:11 +0100, Julien Viet wrote:
>>
>>
>> On Tue, Mar 22, 2011 at 2:47 PM, Matt Wringe <mwringe(a)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(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.
>>
>>
>> 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(a)lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/gatein-dev
>>>
>>>
>>
>>
>>
>>
>
>
12:28 p.m.
On Fri, 2011-03-25 at 17:53 -0400, Matt Wringe wrote:
On Fri, 2011-03-25 at 22:41 +0100, Julien Viet wrote:
> the whole portal login module is not specific to JBoss actually, is it ?
its only used if clustering is enable and the
javax.security.jacc.PolicyContext class exists on the classpath. So its
only used for JBoss.
I also don't think the login method will ever do anything either since
it will only do something if the password is a rememberme password. As
far as I can tell it will never receive a rememberme password here.
Only the commit method appears to do anything, and all its doing is
adding the credentials to the session.
The PortalLoginModule only seems to exist to work with the
ClusteringSSOFilter.
>
> it would be great that you describe your changes so Alain that worked on that
subject and myself can have an overview of the changes and give our opinion.
Ok, I think I understand the issues a bit better now. We need to have a
mechanism to retrieve the actual password for wsrp ws-security and for
clustering sso. We have a few options:
1) store the actual password in the http session. This is currently
being done in the PortalLoginModule if the clustering exo.profile is
active.
1.1) this currently works for clustering sso, but would require another
profile type to activate for ws-security (since we don't want to require
clustering for ws-security to work).
Has some issues with JBoss specific code in the gatein java classes and
hardcoded profile names in java classes. But its easy to add the new
profile requirement.
or
1.2) We can clean up this code a bit better and make it less dependent
on profiles.
We can remove the PortalLoginModule class since its only used for the
ClusteringSSOFilter.
The WCILoginController already adds the credentials to the request
session and removes them in the GenericAuthentication.login method**. We
could just not remove the credentials in the GenericAuthentication.login
method.
This would leave the credentials always available in the session
regardless of the active exo.profiles.
Makes it easier to access for the ws-security case as we don't need a
new profile, still requires the ClusteringSSOFilter class for
clustering.
2) change how we handle rememberme and tokens so that we don't need to
pass the credentials as url parameters on a redirect. This should allow
us to use the actual passwords and get rid of need for the
ClusteringSSOFilter and PortalLoginModule classes. It should make it
easier to access the proper credentials in the ws-security and will make
things work in a more standard manner for clustering.
Don't know how exactly to handle this situation. We could switch to
using programmatic login, but this would require server specific code as
it wont work in the generic case (unless using servlet 3.0 containers).
Maybe have the login.jsp automatically submit the form if the username
and password are passed to it?
1.2 is probably the most realistic option at this point and requires
minimal changes. Any thoughts on this?
**: note if there is a reason why these need to be removed here, please
note that it only gets removed in the GenericAuthentication.login
method, not the servlet 3.0 server specific ones.
> On Mar 25, 2011, at 9:58 PM, Matt Wringe wrote:
>
> > On Wed, 2011-03-23 at 15:11 +0100, Julien Viet wrote:
> >>
> >>
> >> On Tue, Mar 22, 2011 at 2:47 PM, Matt Wringe <mwringe(a)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(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.
> >>
> >>
> >> 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(a)lists.jboss.org
> >>> https://lists.jboss.org/mailman/listinfo/gatein-dev
> >>>
> >>>
> >>
> >>
> >>
> >>
> >
> >
>
4800
days inactive
4808
days old
10 comments
3 participants
participants (3)
-
Boleslaw Dawidowicz -
Julien Viet -
Matt Wringe