On May 21, 2007, at 12:35 AM, Dennis Dam wrote:
Hi,
for a project we have two versions of the same portal running under
two domains, within one Jetspeed instance. One domain is (semi-)
public, the other is restricted to a certain group of users. The
question is: how can I configure Jetspeed with two authentication
handlers ?
One approach I started with is refactoring the current way the
login procedure works. This approach works as follows (as far as I
could track it):
- not authenticated yet ? you get redirected to a login url
- the login url is handled by the LoginServlet, which delegates the
request to Jetspeed for generating a nice page
- the html page with username/password will post the data to a
login proxy url
- the login proxy request is handled by a dedicated servlet which
puts the username/password (and some other stuff) in the session,
and redirects to a redirect url
- the login redirect url has a security-constraint in web.xml,
which makes the container make a call to Jetspeed's
DefaultLoginModule, which uses a singleton object to get the user
manager for authentication.
- if authenticated, the login redirector servlet will redirect to
the original URL.
Ok. So I figured , I have to somehow select the right LoginModule,
which authenticates users based on group membership. That's why I
don't want container-based authentication, since I am then unable
to select the appropriate LoginModule. I changed the login flow as
follows:
- the part until the login proxy stays the same
- the login proxy servlet is replaced by a new servlet however, a
"LoginAuthRedirectServlet", which does the authentication by itself
and then redirects to the url stored in the session. It does this
by retrieving a LoginContextSelector (a new class) via Spring ,
which will select the correct JAAS LoginContext name based on the
request. The code :
if (Jetspeed.getEngine() != null)
{
Object obj = Jetspeed.getEngine().getComponentManager
().getComponent(LoginContextSelector.class.getName());
if (obj!=null){
LoginContextSelector selector =
(LoginContextSelector) obj;
String loginContextId = selector.getLoginContextId
(request);
try{
LoginContext ctx = new LoginContext
(loginContextId);
ctx.login();
} catch (LoginException e){
} }
}
Now if you set multiple login contexts in the JAAS configuration
file (login.conf), you can have two separate authentication
handlers, for example:
Context1 {
org.apache.jetspeed.security.impl.Context1LoginModule required;
};
Context2{
org.apache.jetspeed.security.impl.Context2LoginModule required;
};
The loginmodules are wired to their respective usermanagers, with
their own unique authentication domain configuration. The
disadvantage of this approach is that it's kind of incompatible
with the current security implementation, which assumes there's
only one usermanager. But .. even if there was support for multiple
usermanagers, I'd have to add a lot of Spring configuration, for
example define two separate usermanagers, with their own
configurations, which in my case is LDAP (this config is quite
bloated).
Another approach would be to use one authentication configuration,
and use different authroization schemes.. But I don't want users to
login if they are not authorized to see anything at all.
So my question, does anyone have experience with setting up a
similar authentication scheme as mine ? Is my approach way to
difficult?
One option is to configure two or more User Security handlers
Here we show a diagram of the Security SPI architecture:
http://portals.apache.org/jetspeed-2/multiproject/jetspeed-security/
arch.html
For version 2.2, I would like to better abstract this concept into a
"realm" of users, which could have their own subsite and login mechanism
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
