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 17:12:25 GMT
James Davidson wrote:

> > src/share/org/apache/tomcat/core/FileRequestSecurityProvider.java (NEW)
> >
> >     - Simple implementation of the RequestSecurityProvider
> >       interface that utilizes text-based configuration files (perhaps
> >       in XML, since we need an XML parser anyway) to define
> >       users, passwords, and the roles they can play.
>
> Would you try to support .htaccess files?

Rather than .htaccess files (which have a lot of dependencies on Apache
modules), I was originally thinking of something more like the password files
you can create with the Apache "htpasswd" utility.  You'd have to add some
mechanism to assign users to roles, but that would not be to hard, perhaps even
using the concept of a "group" to be a role.

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>

Passwords should be encrypted rather than cleartext.  I've seen a couple of
Java implementations of crypt() lying around the net -- we could approach one
of the authors about contributing their code for this, unless there's an
implementation readily at hand.  A simple command line utility like "htpasswd"
to go along with this would be really nice for adding new users and/or changing
passwords.

Other RequestSecurityProvider implementations would get their data from other
places -- databases (via JDBC), directory servers (via JNDI), or even the
underlying web server (Costin's idea to go back and use Apache's authentication
stuff through the connector).  The idea of the file-based implementation is to
be a proof of concept implementation, and to meet the needs of developers who
might want to be writing the functionality parts of their apps before the
security parts have been created yet.

>
>
> >     - NOTE:  It is not clear how the J2EE reference implementation
> >       can perform all of the required authentication and access control
> >       checks, given the existing Interceptor functionality.  Of course,
> >       that's probably me not knowing the code well enough yet.  Further
> >       discussions with the J2EE reference implementation team may
> >       generate modifications to this design pattern.
>
> Harish P. from the J2EE RI team can give you all the gory details (or at
> least most of them as they relate to integrating with Tomcat). He's
> currently using the interceptors and security provider to integrate with a
> full security system (based from the J2EE side) that implements all of the
> functionality found in the web app deployment descriptors.
>

I will definitely be in communication with Harish on this topic.

>
> Overall, a very well researched and built proposal. It seems to be
> architecturally sound given how the current Tomcat source base is
> structured. Craig, I think you've set the standard for proposing short term
> plans. :)
>

Thanks ... I hope the resulting code (and in particular the amount of internal
Javadoc comments) can do the same :-).

>
> +1 on moving this forward.
>
> .duncan
>

Craig



Mime
View raw message