tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Craig R. McClanahan" <cmcclana...@mytownnet.com>
Subject Re: [VOTE] Short Term Plan: Add Security Management Capabilities to Tomc
Date Sat, 16 Oct 1999 20:22:31 GMT
James Davidson wrote:

> > Now that we need XML parsing anyway, for reading the server configuration
> and
> > deployment descriptors, it probably makes more sense to read the user and
> role
> > information from an XML file -- perhaps:
> >
> > <Users>
> >     <User username="craigmcc" password="xxxxx">
> >         <Roles>
> >             <Role>developer</Role>
> >             <Role>committer</Role>
> >         </Roles>
> >         <!-- Other subelements would be possible -->
> >     </User>
> > </Users>
>
> Actually how about turning that a bit inside out and:
>
>     <tomcatpasswd>
>       <user name="duncan" password="32kalkf902"/>
>       <user name="craigmcc" password="23asdfjask2"/>
>       <user name="costin" password="659asdfk39"/>
>       <role name="pmc">
>         <member>duncan</member>
>         <member>craigmcc</member>
>       </role>
>       <role name="committer">
>         <member>duncan</member>
>         <member>craigmcc</member>
>         <member>costin</member>
>       </role>
>     </tomcatpasswd>
>
> Either way, you have to reference roles in user defs or users in role defs.
> The question I guess is which way is more "natural".
>

Thinking in terms of where Tomcat is going to use this data repeatedly (to
authenticate users, and to answer the isUserInRole() question) is what led me
to the former approach (users contain roles).  It also matches my mental map of
which concept is more "important", because if a user cannot authenticate
themselves with the correct password, the roles attached to that username are
not relevant

Of course, an RSM implementation is probably going to cache the contents of
this file into internal data structures anyway -- since they are pretty much
isomorphic it probably doesn't matter all that much.  This is my first non-toy
development for XML, so I will happily bow to the experience of others who have
designed these kinds of data formats.

>
> > I've seen a couple of
> > Java implementations of crypt() lying around the net
>
> What about using java.security.MessageDigest with SHA-1 or MD5? It's in JDK
> 1.1. It's got to be better than crypt... :) And, you don't ever need the
> password back out, you just need to compare. Just a thought.
>

Sounds good to me, as long as it's universal across 1.1 and 1.2 platforms, can
be exported, yadda yadda yadda.  You're right -- I'm only counting on a one-way
encryption just like Unix password files (and just like Apache htpasswd
files).  The security manager interface will have an authenticate method taking
an HttpServletRequest as an argument (so that the interface has no dependencies
on which type of authentication you are using).  When doing Basic
authentication, you can just encrypt the password included in the header and
compare to the encrypted stored version.

Craig



Mime
View raw message