On Nov 18, 2008, at 3:02 PM, James Winburn wrote:
Hey guys,
I'm having some problems using SSO in Jetspeed. The documentation
seems
a bit terse and makes actually using the SSO portlets frustrating.
I focused on the SSO Web Content portlet. A number of problems came
up.
1) Setting up the default www.nytimes.com <http://www.nytimes.com/>
credential. From what I was able to get from the documentation, all I
need to do is supply a username and password in the "SSO Principal"
and
"SSO Credential" fields. I supplied this information and saved the
"Edit Preferences". The NY Times page did come up, but not logged in.
And attempts to log in manually were unsuccessful. I checked that I
had
a correct username/password by manually pointing the browser to the
site
(i.e. outside the portal.) It not only came up, but did so in a
logged
in state.
It used to login successfully. Not really sure what has changed. I
tried debugging it quickly, and I was getting cookies back.
Will try to find more time to look into this. Seems that we need a
more reliable example (a site that doesn't change its login so often)
2) I then tried to set up SSO for a different site. This one uses a
separate window for logging in. I blanked out the sso.form.Action
field
(since I didn't know what the action from the window might be). I
also
supplied a valid Username/Password in "SSO Principal" and "SSO
Credential" (as before.) Everything else was left untouched. This
time when I navigated to the page with the SSO Web Content portlet,
the
login window came up again. When I supplied the username/password
again, the app logged in (which was what I was hoping for) but then
completely took over the browser. All I had was a single IE tab with
the app. Attempts to use the back button brought back the portal (and
the page) for an instant, but the web app took control of the browser
again.
I'm not sure what I'm doing incorrectly. I was hoping some kind soul
could steer me in the right direction. :-)
Nothing. Its a little tricky to get working, and then the rewriting
never works as well as expected.
There are 3 kinds of authentication supported:
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).
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
