tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Arkin <>
Subject Re: authorization providers (was More on JAAS)
Date Wed, 19 Apr 2000 20:58:05 GMT wrote:
> For my current example I'm using groups (either groupOfnames or
> groupOfUniquenames).  I map the role name to the group's
> common name.


> > In our case we have a role entry in a given DN space
> > (uid=...,ou=Roles,...) which lists the users under that role (by DN).
> This is essentially what an LDAP group is.

Yep. We use groupOfNames as the objectclass, and the DN path is
configurable, but we tend to use ou=Roles for J2EE roles.

> I prefer the dynamic group to this route. A dynamic group is a
> groupOfUrls object which stores its members as LDAP queries in
> the form of LDAP URLs.
> A user is a member of the group if their entry would satisify one of
> the LDAP queries. This allows you to have infinitely large groups.
> People also come and go out of the groups as their inividual entries
> are updated, you don't have to update one or more secondary
> group objects.

I didn't know there's a standard way of doing that. I like it.

> You just can't load everything into memory because that could be
> quite large. I easily have over 6000 groups with over a total of
> 25,000+ users (I use groups to manage class roles at our
> university). I'd rather just query the LDAP server when necessary
> and not use memory unecessarily.

I expected the 'roles' list to be fairly small and depend not on the
number of users but on the number of different roles, so a typical
application can be 5 to 40 roles, and actually the smaller the user base
is the larger the role list is. For Internet usually all users fall in
two/three roles, while for Intranet you have a variety of roles.

But I understand your model, which is why I recommend that the login
module hand back a generic interface calls RolesCredentials that
supports isInRole(). One implementation (works in my case) would
populate all the roles during authentication. Another implementation
(works in your case) would keep the LDAP connection properties and
user's DN and make queries to the LDAP server each time it needs to. The
Mozilla SDK would come handy in this case since it supports connection
pooling that your implementation can configure.

> Probably true, but I still think JAAS is a future thing not a current
> thing. We can document how people should do this but I don't think
> we can make it a requirement.

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

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.

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

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)

For now, since 2 is definitely working and 3 is so so, I would recommend
using no. 2, but keeping a design pattern that allows us to optionally
switch to 3. And I use optionally because even some users will rather
use JAAS, some would not change what is working, so expect no. 2 to be
supported way into the future.


> mark
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

Assaf Arkin                                 
CTO, Exoffice Technologies, Inc.              

View raw message