tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Costin Manolache <cos...@costin.dnt.ro>
Subject Re: authorization providers (was More on JAAS)
Date Wed, 19 Apr 2000 21:23:47 GMT
One question I have - is it possible to get the list of roles at
authentication time?  If that is true, there will be no need for
a callback. The callback may be needed only if the number
of roles is too big or the auth repository only allow "checkUserInRole",
not "getUserRoles" ( nothing is too paranoid in authentication systems).


> How about the following, and I think this would be the best short-term,
> long-term solution:

I mostly agree with that - with the only exception that the set of
interfaces
should be independent of tomcat core or internals.
For example Realm depends on a number of internal interfaces in Catalina,
and ReqSecurityProvider depends on tomcat.core.

We can add a tomcat.security package and define our favorite set of
authentication interfaces. It will work both in Catalina, tomcat, or any
other
system ( sort of mini-JAAS). It's important to keep it independent - not
only
for reuse, but also as design. After all - authentication is a serious
subject,
not just a small piece of tomcat.

We add interceptors for tomcat.security- that is not very hard, and after
it's done there is no need to argue.
We add interceptors for JAAS - there is no point in adding an extra layer
on front of JAAS.


> 1. We define a set of interfaces for a J2EE principal and roles
> credentials and a way to authenticate given no user, user/password,
> user/certificate, cookie. The container only uses these interfaces.

The container will use these interfaces in most cases - "only" is too
strong :-)
( and tomcat will use the apache modules if it runs in "integrated"
mode - the java interfaces will not be called in this case )


> 2. An implementation can run directly in the container supporting just
> these interfaces.

+1

> 3. An implementation can use JAAS to talk to other login modules that
> use these (or other) interfaces and is responsible for all conversions
> (e.g. user/password to UserPasswordCredentials)

+1

Costin


Mime
View raw message