Hi Æde,
First of all, without the error stack trace you've mentioned below it is difficult to assess the problem(s) you are
encountering.
In general, it seems you've already followed (most of) the right steps to get
your SSO integration working.
If you will need a custom SecurityValve depends on your requirements but on the
first outset I would think not.
For NTLM its custom SecurityValve is used to allow *both* NTLM and "normal"
authentication (as fallback).
In your case though it looks like you only need/depend on the external SSO system for authentication and then you might
just need a custom/extended PortalFilter for initializing your own Subject.
If you have written your own Filter not based upon or extended from PortalFilter please take a look at the PortalFilter
class because it already contains most if not all the required features you might need.
Regards,
Ate
Æde van der Weij wrote:
Hi all,
I'm working on a project where the Jetspeed Portal needs to be integrated with
a Liberty compliant Single Sign on Implementation. It provides two methods:
* let a (Apache) server authenticate and validate request and reverse proxy the
request to Jetspeed,
* or let your Jetspeed validate the request.
In the first scenario there a request header is added with information about
the user (userid, username and roles). In the second case you have to take care
of that you self. We've choosen the first option to start with, so we can rely
on every request to be from an authenticated user. The second one can always be
implemented....
We borrowed some of the concepts that are used for the NTLM Authentication
(http://portals.apache.org/jetspeed-2/guides/guide-ntlm.html). A custom Filter
extracts the user information from the request header, wraps the orginal
request with a custom RequestWrapper and provides it with a newly constructed
Principle if the necessary information can be extracted. We can see that the
wrapped request is propogated to the portlets when we provided a header with
some bogus value. A bogus value results in an empty (null) Principal. When we
provide a valid value and a Principal can be constructed an exception somewhere
in the pipeline is the result. I don't have the exact stacktrace at hand at
this moment, but can provide it later on when requested.
The NTLM has its own SecurityValve implementation and that's probably what we
need to create ourselves. Unless the default implementation can be tweaked to
deal with our Principal. This should be possible with the Spring configuration
files, but I don't know where to start...
Is there some one out there who has experience with this type of thing and give
some pointers? I've seen the Single Sign On concept of authenticating,
validating and enriching the request at other implementations. This should not
be a too unique situation? Any help is greatly appreciated!
Regards,
Æde
_________________________________________________________________
Express yourself instantly with MSN Messenger! Download today it's FREE!
http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
