<br><br><div class="gmail_quote">On Tue, Mar 22, 2011 at 2:47 PM, Matt Wringe <span dir="ltr"><<a href="mailto:mwringe@redhat.com">mwringe@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div><div></div><div class="h5">On Tue, 2011-03-22 at 00:08 +0100, Julien Viet wrote:<br>
><br>
><br>
> On Mon, Mar 21, 2011 at 2:56 PM, Matt Wringe <<a href="mailto:mwringe@redhat.com">mwringe@redhat.com</a>><br>
> wrote:<br>
> Hi,<br>
><br>
> For wsrp ws-security we need to pass the username and actual<br>
> password<br>
> (not token) between the consumer and producer. We need to do<br>
> what is<br>
> currently done with the ClusteredSSOFilter and<br>
> PortalLoginModule when<br>
> the clustering exo.profile is enabled.<br>
><br>
> What is the current policy for dealing with exo.profiles? I<br>
> can't seem<br>
> to find much info on it other than when to use it for the<br>
> clustering<br>
> setup.<br>
><br>
><br>
><br>
> When the server boots it shows the active profiles on the console<br>
> like:<br>
><br>
><br>
> Mar 21, 2011 11:57:38 PM org.exoplatform.container.RootContainer<br>
> <init><br>
> INFO: Active profiles [tomcat]<br>
><br>
><br>
> The server determines a profile by itself (tomcat for tomcat, etc...),<br>
> additional profiles are added with the -Dexo.profiles VM argument with<br>
> a comma separated list<br>
><br>
><br>
> When you want to activate a part of the configuration you have to<br>
> depend on a profile, here again you can specify a list of profile with<br>
> a comma separated list.<br>
><br>
><br>
> You can determine which elements of the configuration accepts a<br>
> profile by looking at<br>
> the <a href="http://www.exoplaform.org/xml/ns/kernel_1_1.xsd" target="_blank">http://www.exoplaform.org/xml/ns/kernel_1_1.xsd</a> schema, normally<br>
> it should answer your needs if you are going to activate some part of<br>
> the server this way.<br>
><br>
> Would it be acceptable to create a 'sso' or 'wsrpsso' profile<br>
> which<br>
> would also enable the authenticated credentials propagation in<br>
> the<br>
> ClusteringSSOFilter and PortalLoginModule? Or is the profile<br>
> setup<br>
> reserved for other tasks?<br>
><br>
><br>
> This makes sense to me, although the clustered sso filter is<br>
> configured differently because it's a servlet filter, it uses<br>
> (unfortunately) programmatic hardcoded profile selection with the<br>
> code: ExoContainer.getProfiles().contains("cluster")<br>
><br>
><br>
> Also I would like to move this server dependent code to the WCI module<br>
> at some point (I wanted to do it currently in trunk, so this code<br>
> would move to a proper location and could be more easily tested), but<br>
> doing that would need to bring a dependency of this filter onto the<br>
> exo kernel which is something we would like to avoid. Perhaps there is<br>
> something creative than can be done, to keep flexibility and avoid the<br>
> duplication in WSRP.<br>
<br>
</div></div>An option would be to change the code in wci and allow for the retrieval<br>
of the actual password when presented with the username and token.<br></blockquote><div><br></div><div>There is a notion of token store in GateIn itself, I don't know if it is related or not.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
If we can create a type of password store in wci, then we don't need to<br>
store the password in the servlet session during the a portal login.<br></blockquote><div><br></div><div>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).</div>
<div>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.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
This would be enough for the wsrp ws-security, but I think the<br>
clusteringsso filter would still need to exist.<br></blockquote><div><br></div><div>My concern was about moving this server specific part to the JBoss AS WCI SPI implementation.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="im"><br>
> Actually I don't know exactly how you plan to use it in WSRP, would it<br>
> be on producer side in the producer war file ?<br>
<br>
</div>Its not on the producer side, its on the consumer side. It basically<br>
works like this:<br>
- a user logs into the consumer portal<br>
- a user goes to access a remote portlet<br>
- the users credentials are sent from the consumer to the producer<br>
- the producer authenticates and verifies the credentials and use that<br>
to make any role based decisions.<br>
<br>
The issue is with retrieving the actual password in the consumer and not<br>
a password token (since the wci token is only valid for the original<br>
server).<br></blockquote><div><br></div><div>So the consumer would use the TokenStore to retrieve the user password to propagate it once a user has established authentication ?</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<br>
This is all very similar to how the clustering sso currently works, and<br>
I would like to reuse as much code between the two.<br></blockquote><div><br></div><div>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.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<br>
Using the current implementation if we enable the clustering profile (or<br>
create another profile which only handles the password part and not full<br>
clustering) then we can retrieve the actual password in the consumer in<br>
the same manner as the clustering setup.<br></blockquote><div><br></div><div>I understand that.</div><div><br></div><div>The TransientTokenStore worked this way when a user performs a programmatic login:</div><div><br></div>
<div>1/ store username/password in store and get a token</div><div>2/ perform java EE authent with username and password = token</div><div>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</div>
<div>4/ proceed to authent</div><div><br></div><div>this would be similar, except that the token would not be removed from the token store until the user logs out.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div><div></div><div class="h5"><br>
><br>
> Also this code could be stay in GateIn but in a JBoss specific module<br>
> instead. My concern is that any activation of the cluster code in<br>
> tomcat could lead to a class not found exception of<br>
> the org.jboss.web.tomcat.security.login.WebAuthentication class. But<br>
> this is a different concern than the one you are expressing here of<br>
> course.<br>
><br>
><br>
> I would rather not have to duplicate this effort in the wsrp<br>
> code.<br>
><br>
> Thanks,<br>
><br>
> Matt Wringe<br>
><br>
> _______________________________________________<br>
> gatein-dev mailing list<br>
> <a href="mailto:gatein-dev@lists.jboss.org">gatein-dev@lists.jboss.org</a><br>
> <a href="https://lists.jboss.org/mailman/listinfo/gatein-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/gatein-dev</a><br>
><br>
><br>
<br>
<br>
</div></div></blockquote></div><br>