tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Craig McClanahan" <>
Subject Re: cvs commit: jakarta-tomcat/src/share/org/apache/tomcat/core
Date Mon, 25 Oct 1999 21:19:26 GMT wrote:

> > >   RequestAdapterImpl will be the "default" setter-based implementation.
> >
> > Somewhere in this constellation of new interfaces and classes, you need a way for
the protocol adapter to set the value that is
> > ultimately returned by HttpServletRequest.isSecure().  In the original Tomcat implementation
this was misplaced as part of the
> > RequestSecurityProvider interface.  Only the protocol adapter knows the right answer.
 (Default value should be false, so you only need
> > to worry about setting it when you have an adapter that may be used on a secure
> getScheme() == https ?

For now that is sufficient.  You'd want a general mechanism to deal with cases where the protocol
adapter considered a connection to be
"secure" even when SSL was not used -- or perhaps returning false if SSL was used but only
with 40-bit keys.

My primary concern is that the isSecure() logic does not belong in the RequestSecurityProvider
interface (proposed to be replaced by
RealmConnector) -- it's not an issue that has anything to do with authentication or access
control lookups.

> > A second issue that will come up soon is security-related.  If you're running with
the Apache connector, you want to be able to go back
> > to Apache to answer the "isUserInRole" question -- I'm assuming that you will have
already populated the getRemoteUser() value, so you
> > can map the role to Apache's notion of groups.  The issue is, nothing in the Request
or Context implementations knows what the protocol
> > adapter object used for this request was, so there is no object through which to
make a callback.
> > The most reasonable thing (at first thought) seems to be to add a property in the
Request that lets you trace back to the originating
> > protocol adapter so that the question can be asked.
> Request will have a getRequestAdapter(), I want to have more feedback before going this
> ( and converting all exisiting connectors to use RequestAdapter).
> I'm not sure which is the best way to "expose" Server API ( and callbacks), but I would
not use
> RequestAdapter for "generic" callbacks.

The implementation of RealmConnector that wanted to go back through Apache would cast this
reference to the AjpXX-specific protocol adapter
class that was needed.  I don't think you need a general "callback" API.

> What's the difference between "isUserInRole" and  "getRemoteUser" ?
> ( Adapter.getRemoteUser() will return not-null if Apache checked the user name
> and password )

I'm assuming that getRemoteUser() is being populated by Apache already (based on the request
URI being processed by a <Location> directive or
something like that).  From the username, it's feasible to derive the answer to getUserPrincipal().
 The concern with these two methods is
authentication -- has this user proven their identity?

The use of roles is for access control -- now that the system knows who the user is, what
things are they allowed to do?  In a pure Apache
world, you control this by a "require-user" directive (any authenticated user can do something),
by explicitly listing the user(s) allowed to
do something, or by listing the group(s) whose members are allowed to do something.  The physical
representation of users and groups depends
on which Apache authentication module you are using.

Apache doesn't really have the concept of "roles" in its security model (although the concept
of GET, POST, and PUT permissions is somewhat
the same), and the servlet API doesn't have the concept of "groups", so there is something
of an impedance mismatch to deal with.  However,
it would seem reasonable to answer the following question:

    if (request.isUserInRole("manager")) {
        ... do something for a manager ...

by mapping it back to Apache and asking "is the currently authenticated user a member of the
'manager' group?"  That way, you can use
Apache's existing mechanisms for both authentication and for access control.

> Costin


View raw message