tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Arkin <ar...@exoffice.com>
Subject Re: authorization providers (was More on JAAS)
Date Wed, 19 Apr 2000 21:30:04 GMT
Costin Manolache wrote:
> 
> 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).

I would rather than the container not deal with either of that, but
leave it to the authentication module to determine. Some modules will
pick up the role list immediately, some will figure them out when
isUserInRole() is called. Therefore, the container should call
isUserInRole() on some interface, but never call getUserRoles().


> I mostly agree with that - with the only exception that the set of
> interfaces
> should be independent of tomcat core or internals.

+1 The interface should be security specific not container specific.

> 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 :-)

"Only" as in, if the container makes a request to a login module for the
purpose of J2EE authentication & authorization it will use just these
interfaces and no other extensions. If the container talks to someone
else for any other purpose (say just authentication) it can use any
other interface that makes sense, however, that is a container issue and
a generic authentication module is not aware of that.

> ( and tomcat will use the apache modules if it runs in "integrated"
> mode - the java interfaces will not be called in this case )

+1 In which case the container needs some other way to authenticate.

arkin


> 
> > 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
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org

-- 
----------------------------------------------------------------------
Assaf Arkin                                           www.exoffice.com
CTO, Exoffice Technologies, Inc.                        www.exolab.org

Mime
View raw message