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)?
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.
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.
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 think I shall also experiment with programmatically and preemptively
populating user preferences for dedicated SSO portlet instances and
see how that goes as well...
-aaron
On Wed, Sep 24, 2008 at 4:51 PM, David Sean Taylor
<[EMAIL PROTECTED]> wrote:
>
> On Sep 24, 2008, at 11:40 AM, Aaron Evans wrote:
>
>> Thanks for the response David.
>>
>> Is it possible to get the Subject within other portlet applications
>> (besides the jetspeed application)?
>
> We create the Subject in the Security Valve. So what you could do is get it
> via the requestContext.getSubject() method in your own valve, placed after
> the security valve in the pipeline.
>
>>
>>
>> Are the SSOPortlets intended to be deployed under the jetspeed context?
>
> no
>
>>
>>
>> I would prefer to extend the SSOPortlets and deploy them in another app.
>>
>
> Getting the Subject on the request in another app is also possible. Just get
> the request context from your request object such as in a JSP
>
> <%@ page import="org.apache.jetspeed.request.RequestContext"%>
>
> <c_rt:set var="requestContext"
> value="<%=request.getAttribute(RequestContext.REQUEST_PORTALENV)%>"/>
> <c:set var="mySubject" value="${requestContext.subject}"/>
>
>
>> If I can't get at the Subject in another app, I suppose I could always
>> extend the UserManagerImpl and have it stuff the password in the
>> user's preferences in the getUser method.
>>
>> In fact, maybe that's the easiest way to go?
>
> Well, I would consider stuffing in the SSO store
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
