tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Johan Peeters <>
Subject Re: authentication - JDBC Realm
Date Thu, 07 Sep 2000 02:14:35 GMT

"Craig R. McClanahan" wrote:

> Johan Peeters wrote:
> > "Craig R. McClanahan" wrote:
> >
> > > Johan Peeters wrote:
> > >
> > > > Hi,
> > > >
> > > > In the servlet spec, it is stated that a security role can be mapped to
> > > > a user group or to a principal. Am I right in thinking that only the
> > > > latter is supported in the JDBC Realm implementation?
> > >
> > > No.  Even with the default memory realm (i.e. the contents of the
> > > "$TOMCAT_HOME/conf/tomcat-users.xml" file), you can think of a group as "all
> > > principals who have been assigned the same role name".  If there is only one
> > > such user, then you have just mapped a security role to an individual
> > > principal.
> > >
> >
> > Hmmm, so basically, the term 'user group' in the spec should be interpreted as
> > simply indicating that there can be many users to a role?
> >
> This isn't necessary a hard and fast rule, but I imagine that most systems will
> have a one-to-one mapping between roles (in the web app descriptor) and groups (in
> the security domain).  For example, if I wanted to write a Realm implementation
> that mapped to the users and groups supported by most Apache authentication
> modules, I would certain map roles to groups.
> > We envisaged user groups as a separate entity (class/table/...), allowing to
> > pre-configure access rights for groups of users, i.e. before individual users
> > are registered. The following steps would be taken:
> > 1. a superuser defines one or more groups
> > 2. the superuser grants access rights to particular web resources (roles) to
> > each group
> > 3. the superuser registers individual users as part of a group.
> If you substitute the word "role" for the word "group" in the above steps, aren't
> we talking about exactly the same thing?

I don't think so. As I see it, a role says that a user who has/is-in a role has access
to a set of web resources. In this sense, a role can be seen as a set of web resources.
In our scheme, a group says that a user who is part of the group can take any of a set
of roles which have been assigned to that group, i.e. the user gets access to the web
resources which are in the union of the roles of the group.

> The only additional step would be that the sysadmin deploying your web apps would
> adjust the security role names used in the web.xml file to match the ones in your
> administrative database.
> >
> > The advantage of this in an application with many roles will be obvious.
> > But, if I understand Craig correctly, it is not the spec's intention to support
> > this group notion. Sorry to press this point, but I do not want to embark on
> > developing a home-grown scheme if there are standard ways of doing this.
> >
> The spec's intention is to define a way to protect web application resources based
> on role membership.
> What a "role" actually means is *totally* up to the servlet container to define.
> For Tomcat, we've defined an interface so that you can in fact install your own
> definition of what it means, using whatever underlying technology is appropriate
> (XML file, database, LDAP directory server, NT users database, Unix password files,
> ...)  All you have to do is write your own implementation of the Realm interface,
> and configure it in server.xml, and Tomcat will ask *your* security technology to
> authenticate users, and what roles they have enabled.  For example, several J2EE
> servers embed Tomcat as their web layer -- and they provide a Realm implementation
> that interacts with the same definition of users and roles that the server uses to
> control access to EJBs.
> For your purposes, it sounds like "role == group" is a good way to set things up,
> particularly if you are trying to map roles onto an existing security policy domain
> that is based on groups.
> Craig
> ====================
> See you at ApacheCon Europe <>!
> Session VS01 (23-Oct 13h00-17h00):  Sun Technical Briefing
> Session T06  (24-Oct 14h00-15h00):  Migrating Apache JServ
>                                     Applications to Tomcat



Johan Peeters
Software Architect - Net Commerce
Alcatel - Gen. De Wittelaan 11 A bus 1 - 2800 Mechelen - Belgium
Phone: +32 15 29 3427 Fax: +32 3 240 4800

View raw message