[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)
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>
-->
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
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 think I shall also experiment with programmatically and preemptively
populating user preferences for dedicated SSO portlet instances and
see how that goes as well...
