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]
