tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Craig R. McClanahan" <>
Subject Re: Short Term Plan: Add Security Management Capabilities toTomcat
Date Sat, 16 Oct 1999 23:14:28 GMT
Harish Prabandham wrote:

> Hi,
> I like this approach:
> wrote:
> > > ... Actually how about turning that a bit inside out and ...
> >
> > Any good DBA would tell you that neither is in fourth normal form, with the
> > correct form being more like the following:
> >
> >     <tomcatpasswd>
> >       <user name="duncan" password="32kalkf902"/>
> >       <user name="craigmcc" password="23asdfjask2"/>
> >       <user name="costin" password="659asdfk39"/>
> >
> >       <role name="pmc"/>
> >       <role name="committer"/>
> >
> >       <auth user="duncan" role="pmc"/>
> >       <auth user="craigmcc" role="pmc"/>
> >       <auth user="duncan" role="committer"/>
> >       <auth user="cragmcc" role="committer"/>
> >       <auth user="costin" role="committer"/>
> >     </tomcatpasswd>
> >
> >
> Also, please do not forget that:
> A. In a typical system, there are both users and groups.

So far, my thinking has been that the concept of "groups" and the concept of
"roles" are pretty similar.  In fact, if you want to build a
RequestSecurityProvider that goes back to Apache to do the lookups, you would
map roles from the servlet API to groups in Apache.

> B. There could be multiple security domains (or realms) for a
>     web server.

> I am not asking for support for multiple security domain, but the
> schema design should not preclude such a possibilty.

What I've proposed is that a RequestSecurityProvider be connected at the Context
(i.e. the web application) level, of which there can be several in one
container.  The RequestSecurityProvider associated with a particular Context can
be configured based on the initialization parameters specified for that Context.

If two web apps want to use the same security domain (realm), they would have
identical configuration parameters.  For example, using a JNDI based directory
of users and roles, they would both specify the same JNDI connection values.
Thus, the two apps would both be managed by the same security domain.  (They
would still end up with separate instances of the implementation class, in the
same way that you can have two servlet instances for the same servlet class,
mapped to different URI patterns.)

If two web apps want to use the same security technology (say, JNDI again for
sake of comparison) but different domains, their implementation class names
would be the same, but their connection parameters would be different (perhaps
using two different LDAP servers, or using the same server with different base

If two web apps want to use different security technologies (say, JNDI for one
and a legacy database accessed via JDBC for another), they can do that as well.
They would declare different implementation classes, each with their own
initialization parameters.  The two web apps can coexist peacefully without
interfering with each other.

I think that covers all the arrangements that make sense, in a very flexible

> Thanx
> Harish


View raw message