Comments below... On Mon, Sep 29, 2008 at 12:09 PM, David Sean Taylor <[EMAIL PROTECTED]> wrote: > > [EMAIL PROTECTED] www.onehippo.com > San Francisco - Hippo USA Inc. 101 H Street, Suite Q Petaluma CA 94952-3329 > +1 (877) 41-HIPPO > Amsterdam - Hippo B.V. Oosteinde 11 1017 WT Amsterdam +31(0)20-5224466 > > > > On Sep 26, 2008, at 2:16 AM, Aaron Evans wrote: > >> Thanks for the tips David, most helfpul. >> >> Quick question before I start on general ramblings: >> >> If I did want to programmatically set some user-specific portlet >> preferences, would I do that with the >> org.apache.jetspeed.prefs.PreferencesProvider component (defined in >> prefs.xml)? > > Yes. Just want to comment that we are refactoring the Prefs for 2.2 release > (scheduled for beginning of November, ApacheCon) >
Ok, I'll keep that in mind. >> >> Here is an update on my progress for anyone who might find themselves >> in a similar situation... >> >> So, goal #1 was accomplished and that was to capture the clear text >> password in the Subject's private credentials. >> >> This was much harder than it sounds because normally the Credentials >> are populated by the CredentialHandler via the UserManager. But the >> method signature only provides the principal username, not the >> submitted password. Since the password is stored in SHA-1 encoding in >> LDAP, my implementation has no way to lookup the clear text password. >> The best it can do is to look up the hashed value and use that. >> > We do support bidirectional encoding, but I suspect your passwords are > already generated. For future reference see security-spi-atn.xml: > > > <!-- A Two-way encoding password service which also implements > CredentialPasswordEncoder > this Service can be used instead of for example the default provided > MessageDigestCredentialPasswordEncoder > <bean id="org.apache.jetspeed.security.PasswordEncodingService" > name="org.apache.jetspeed.security.spi.CredentialPasswordEncoder" > class="org.apache.jetspeed.security.spi.impl.PBEPasswordService"> > <constructor-arg index="0"> > <!- secret PBE key password -> > <value>********</value> > </constructor-arg> > </bean> > --> > Yes, our passwords are already generated. But further still, we are using a one-way hash algorithm (SHA-1), so this wouldn't work anyway, would it? > >> There isn't really a good place where you have access to both the >> Subject being constructed and the clear text password. The >> LoginModule *would* be that place but that Subject is discarded. The >> permanent (session) subject is created in the SecurityValve as you >> said. > > We are no longer discarding the Subject, this was fixed for the 2.2 release: > > https://issues.apache.org/jira/browse/JS2-238 > > warning: only tested with Tomcat 5.5 > Ah, excellent. I'll be able to simplify the whole thing and override less components. >> >> >> So, I had to override the LoginRedirectorServlet so that it wouldn't >> erase the password value from the session immediately. Instead, later >> in the pipeline I get the Subject out of the session and create a new >> one that contains private credentials with the clear text password and >> stuff that back in the session replacing the other. >> >> So now all my portlets have access to the subject and the clear text >> password (it was accessible using the API calls you specified). >> >> So now I'm going to experiment with stuffing the creds in the SSO >> store as you suggest. However, I think I'll likely run into problems >> since this is not functioning from the SSO Administration portlets as >> I said in a previous post. I think it doesn't work if you don't use >> the default SPI implementation. Anyhow, I should know more in the >> next few days when I try this out, perhaps I can pinpoint the problem. >> > > I would be interested to know if there is a bug there > Note that as a part of the security refactoring in 2.2 we are also in the > process of correcting the SSO model > I will try to test this out and let you know as soon as I can. > >> I think I shall also experiment with programmatically and preemptively >> populating user preferences for dedicated SSO portlet instances and >> see how that goes as well... >> > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
