Thanks for the response David. Is it possible to get the Subject within other portlet applications (besides the jetspeed application)?
Are the SSOPortlets intended to be deployed under the jetspeed context? I would prefer to extend the SSOPortlets and deploy them in another app. 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? On Tue, Sep 23, 2008 at 10:42 PM, David Sean Taylor <[EMAIL PROTECTED]> wrote: > Sorry for the late response. I had a email server problem and lost a lot of > my lists emails. Just getting things pieced back together, but I don't seem > to be receiving my on posts from this afternoon. see response below > > On Sep 11, 2008, at 10:37 AM, Aaron Evans wrote: > >> Hey all, >> >> I'm finally going to get rolling with trying to tie together some of >> our various web-based service offerings into a single UI under >> jetspeed 2. >> >> So I'm thinking of looking at some of the SSO portlets like >> SSOWebContent or the IFrame one or something similar. >> >> But, I'm seeking some advice because there's a catch. >> >> Here's the deal: we've successfully gotten all of our web application >> service offerings authenticating against a common LDAP server, the >> same LDAP server that we authenticate against for jetspeed.. >> >> So, the user names and passwords for accessing these web applications >> will be precisely the same ones as they are for accessing jetspeed. >> >> Thus, I want to be able to setup some kind of SSO portlet that will >> point at a given URL (which I would like to vary a bit dynamically >> based on some user data) and use the user's jetspeed userID and >> password for the back-end SSO authentication. >> >> Now, our passwords are not stored in clear text but rather a SHA based >> hash. >> >> So, I was thinking that if I modified the authentication mechanism in >> jetspeed to capture the submitted password value at login and store it >> in a session variable, I could then use that value combined with the >> principal's name for the SSO authentication. >> >> Users should not be required to set their userID and password for a >> given remote site themselves, we want to hide all of this from them. >> Nor can they modify the URL we want to send them to but as I said, the >> URL will vary by customer (which is an LDAP/jetspeed group >> incidentally). >> >> Obviously I would have to extend one or more of the SSO portlets to do >> this. >> >> Anyway, I'm just looking for some general advice before I dive too >> deep into this to see if anyone can think of a simpler way to achieve >> something like this. >> > The SSO Component allows you to store credentials associating with a user > (or group of users) and a site(URL). > I think if you got the password out of the Jetspeed Subject, couldn't you > just "authenticate" against your LDAP using it > > You mentioned the SSOWebContent portlet. It supports several kinds of > authentication: > > Basic authentication > is the default and can be supported effectively without even setting > sso.type Just by providing credentials for the domain. The credentials will > not be sent preemptively, but if a 401 request is returned for Basic > authentication, it will be handled properly. Tis is equivalent to setting > sso.type=basic (or sso.type=html (old - now deprecated in favor of calling > it basic). if you set sso.type=basic.preemptive, it will send the > credentials preemptively. > > URL authentication > (query args) is supported as sso.type=url or sso.type=url.base64. By > definition, this type of authentication is preemptive, so no distinction is > made there. > > Form-authentication > is supported with sso.type=form (which is equivalent to sso.type=form.post - > you can also specify sso.type=form.get, if GET protocol is used on the login > form). This form also requires a bunch of other data ( e.g. the action URL, > other args, names of the fields for credentials, etc.). All of this is in an > example that is in the demo portlet.xml. Form-based authentication is also > considred "preemptive", in that it authenticates before any other content is > read. However, it only does it once. If it succeeds, all should be well. If > it fails, the user will have to login by hand (since the initial content URL > will cause a redirect to the login page). > > > The following preferences can be used with the SSO IFrame Portlet in > addition to the standard IFrame preferences > > Preference Usage > sso.type The type of Single signon authentication. Valid values: form > | basic | basic.preemptive | url | url.base64 > sso.url.Credential The name of the credential input field or parameter > sso.url.Principal The name of the user name input field or parameter > SSO Principal The actual user name > SSO Credential The actual crendential value > > Examples of extending the SSOWebContentPortlet, see 2.1.3: SSOTicketPortlet: > > public class SSOTicketPortlet extends SSOWebContentPortlet > > It might be interesting to extend the SSO portlets to use the current > Jetspeed credentials for the user, I guess I never thought of that case > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
