authorization providers (was More on JAAS)

[ma...@mjwilcox.com]

Hi,
I'm glad to see we're having healthy debate on the issue. 

And as someone who has written one of the first extensions of the 
interceptors, here's what I think needs to be in Tomcat.

1) First people should be able freely write security interceptors as 
they see fit. 

I think that we can make this fairly general enough that people will 
be able to add in whatever authentication mechanism they 
need/want. Just look at the Apache authentication modules. Even if 
someone writes a version for a particular protocol (e.g. LDAP) it 
may not fit what a person needs. For example when I went a 
looking for an LDAP module for Apache, I found 2, both based 
around the C API. Which wasn't too bad except that neither one 
supported LDAP groups, something I needed. So I wrote my own, 
primarily to support LDAP groups but also in Net::LDAP which is 
pure Perl, thus I no longer needed a C compiler for the module. 

2) Make the security interceptor into a driver/manager format. 

We should be able to load more than 1 interceptor at a time and 
they should be able to chain themselves together. 

3) we should be able to populate the Roles object
While I can authorize a user per role (e.g. LDAP group), I cannot 
set the Roles value for when someone wants that information from 
request.getRoles().

The good news is that I don't think this has to be that complicated. 

I was able to successfully authenticate users by simply extending 
org.apache.tomcat.request.SecurityCheck and 3 methods:

checkPassword
userInRole
authenticate

I only needed to overwrite authenticate so that I could perform 
module configuration.

What was great about this was that the SEcurityCheck class could 
take care of parsing username and password, making sure that 
any other requirements were met, etc. 

The only item I really lacked was the ability to populate the roles 
as I said before. This could be fixed in the Security Interceptor by 
populating a hashtable or map that was updated on each call to 
userInRole and then passed onto the Request object.

This API works fine for when you are dealing with username and 
password.

But what about X.509 or kerberos? I think perhaps we can solve 
that adding 2 more signatures to the checkPassword and 
userInRole.

Instead of taking username and passwords they could take either 
an array of bytes or a generic Object. The SecurityInterceptor 
would only call these versions of the methods if the method of 
authentication/authorization was not BASIC,DIGEST or FORM.

I'm not exactly sure how to handle multiple interceptors yet. 

The actual implementors of the interceptors could use whatever 
mechanism they wished (JNDI, JAAS, Kerberos, etc) as long as 
they extended the proper class.

The default provider would simply implement this API. We could 
then provide extras if we wanted that people could optionally 
compile and add in, just like you can with Apache.

I'm under a tight deadline right now to finish my chapter that started 
all of this. I'll try to get at least my source code published to the 
Web this week (if people want me to submit it to Tomcat, I can, but 
I'd rather wait until this is settled).

Mark

Re: authorization providers (was More on JAAS)

[Costin Manolache <co...@costin.dnt.ro>]

>
> > * The mechanics of doing something like the
> >   BASIC authentication protocol are generic,
> >   no matter how you validate users.  It is appropriate
> >   to implement this as a request interceptor (SecurityCheck
> >   in Tomcat 3.x, SecurityValve in Catalina).

Or in a BasicAuthenticate class? And FormAuthenticate to
deal with form based authentication ?

And the interceptor just uses the components implementing certain
forms of authentication and the security APIs.

Again: interceptors are not supposed to _implement_ a certain
authentication protocol, but to act as a _bridge_ between various
APIs. SecurityCheck is just one example on how authentication
can be done, and does have everything in it's body just to allow
easy development and allow people to understand the code.
Even in SecurityCheck - most of the code for Form authentication
is moved in a normal servlet, and probably any other form of authentication
can and should be moved.

After all, it is perfectly valid to not declare any authentication method
in web.xml and have the servlet implement it in "user space". That have
quite a few valid use-cases - for example an ISP may host a web
application but will not want to handle users-management.
There is no restriction in the spec that "the only way to use BASIC
authentication is via web.xml ". Having normal "components" for
authentication and only putting them togheter in the interceptor is a
much better design ( IMHO )

Costin



>
> >
> > * The way that you validate a user is fairly generic,
> >   no matter which authentication method (BASIC,
> >   DIGEST, FORM) you choose for your web app.
> >   It's not quite as clear cut because of things like
> >  SSL, where you are tapping into a somewhat
> >   different processing model.
> >
> > So, what you'd like is a generic way for the request interceptor (or Valve) to say
> > "here is a username and a password -- is it a valid combination?"  Thus, you need to
> > define an internal-to-your-request-interceptor API by which that question is asked.
> > As you point out, you don't want the security domain that answers the question to
> > know anything about HTTP.  At the same time, you don't want your BASIC authentication
> > implementation to care abou the differences between looking up users in a database,
> > or a directory server, or whatever.  Thus, in design patterns terms, you want an
> > "adapter" in between.  That's what a Realm interface really facilitates - the
> > implementation adapts the BASIC authentication interceptor's view of the world (very
> > HTTP-centric) to the security domain's view of the world (lots of variations in
> > implementation).
> >
> > The challenge, of course, is how do we standardize how much information from the
> > incoming HTTP request is needed to perform the authentication.  Username and password
> > (or username and a byte array of credentials) cover the simple cases -- it's not
> > clear that they cover all of them.
> >
> > Given that the customer of the Realm interface is in fact a Tomcat component (the
> > authorization interceptor), it doesn't bother me that the Realm interface is Tomcat
> > specific.  This does not at all imply that a Realm implementation must actually do
> > all the work (although that's possible) -- in most cases it will simply delegate to
> > some existing security domain implementation that really does the work.  For example,
> > if you were integrating Tomcat inside a J2EE server, you'd simply adapt to the
> > security domain stuff that already exists within that server, rather than
> > re-inventing it from scracth.
> >
> > How the delegation actually happens is a private decision of the Realm implementor,
> > totally invisible to Tomcat's core servlet container.  Likewise, how Tomcat uses the
> > answers to authentication questions (for example, send an HTTP "Not authorized"
> > response) is invisible to the Realm implementation, and also therefore invisible to
> > the underlying security domain.
> >
> > >
> > > arkin
> > >
> >
> > Craig
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
>
> --
> ----------------------------------------------------------------------
> Assaf Arkin                                           www.exoffice.com
> CTO, Exoffice Technologies, Inc.                        www.exolab.org
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org

Re: authorization providers (was More on JAAS)

[Costin Manolache <co...@costin.dnt.ro>]

>
>
> I think we're in total agreement on this intent.  And I even think that you summarized
> (much more concisely) what I was trying to say.
>
> The issue that raised this long-winded thread was design choices in implementing this
> conclusion.  Tomcat 3.x combines the two concepts in one class (but lets you subclass to
> change realm implementations); Catalina separates the two concepts and lets you combine
> your favorite authentication mechansim and an adapter to your favorite security provider by
> composition instead.

Wrong - tomcat 3.x provide a sample authentication interceptor. The intent was to keep it
simple and concise - so people can easily read the code.
Extending it is just one way to reuse the code inside, and it's probably the easiest.
It's just a prove of how easy it is to add authentication to tomcat - it's 1/2 day of work,
with a lot of time spend in decoding the password.



Costin

Re: authorization providers (was More on JAAS)

["Craig R. McClanahan" <Cr...@eng.sun.com>]

Arkin wrote:

> It's hard for me to comment on this e-mail, it seems to confuse two
> different topics. One is authentication at the protocol level (HTTP,
> WAP, etc) and one is back end authentication and authorization.
>
> The first is totally dependent on the protocol. It might work different
> for HTTP than for WAP, it might work different if Tomcat is standalone
> vs. connected to Apache. It might work different for HTTP 1.0 than 1.1.
>
> The second is totally dependent on the container API defined in the J2EE
> architecture and covers the authentication & authorization of users,
> regardless of protocol. It works the same way whether the protocol is
> HTTP or WAP, RMI or IIOP, client application or server, synchronous or
> asynchronous (JMS).
>
> In my opinion it's Tomcat's responsibility to support at the least an
> HTTP adapter and delegate that to a security provider, but the security
> provider need not understand HTTP specific issues, or even be exposed to
> such issues.
>

I think we're in total agreement on this intent.  And I even think that you summarized
(much more concisely) what I was trying to say.

The issue that raised this long-winded thread was design choices in implementing this
conclusion.  Tomcat 3.x combines the two concepts in one class (but lets you subclass to
change realm implementations); Catalina separates the two concepts and lets you combine
your favorite authentication mechansim and an adapter to your favorite security provider by
composition instead.

>
> arkin
>

Craig

Re: authorization providers (was More on JAAS)

[Arkin <ar...@exoffice.com>]

It's hard for me to comment on this e-mail, it seems to confuse two
different topics. One is authentication at the protocol level (HTTP,
WAP, etc) and one is back end authentication and authorization.

The first is totally dependent on the protocol. It might work different
for HTTP than for WAP, it might work different if Tomcat is standalone
vs. connected to Apache. It might work different for HTTP 1.0 than 1.1.

The second is totally dependent on the container API defined in the J2EE
architecture and covers the authentication & authorization of users,
regardless of protocol. It works the same way whether the protocol is
HTTP or WAP, RMI or IIOP, client application or server, synchronous or
asynchronous (JMS).

In my opinion it's Tomcat's responsibility to support at the least an
HTTP adapter and delegate that to a security provider, but the security
provider need not understand HTTP specific issues, or even be exposed to
such issues.

arkin


"Craig R. McClanahan" wrote:
> 
> Arkin wrote:
> 
> > "Craig R. McClanahan" wrote:
> > > In the case of Catalina's "Realm" interface, the only Tomcat dependency is on
> > > the Container interface.  The rationale is this:  "Realm is an interface that a
> > > security domain must implement to allow Tomcat to authenticate users and
> > > validate roles."  Given that this is the whole point of Realm, it does not seem
> > > like a problem to me -- plus, it allows the security domain to access other
> > > resources of the container if needed.
> >
> > Which means a security provider has to be developed for Tomcat
> > specifically and cannot be used for any other container.
> >
> > > Beyond that, it's not clear whether we can get away with just the current
> > > authenticate() methods, or whether we might also (or instead) need:
> > >
> > >     public boolean authenticate(Request request);
> > >
> > > because we want to allow a realm implementation to access any request
> > > properties it needs to.  This introduces one more dependency on the Tomcat
> > > internals, but it's still a Tomcat internal API -- that's OK with me.
> >
> > In my opinion an authentication interceptor (Tomcat specific) should be
> > used for that, not a generic security provider. A generic security
> > provide has no notion of HTTP. In fact, it may be called at any point
> > without any relation to an HTTP request.
> 
> > > Note:  a Realm implementation that itself uses JAAS (on a 1.3 platform)
> > > certainly makes a lot of sense.  But it is not sufficient for many other cases
> > > -- for example, a J2EE server with Tomcat embedded in it will have it's own
> > > notion of users and roles for use by the EJB side, and you want the servlet
> > > side to attach itself to that existing implementation.
> >
> > Actually the Servlet container would server as the point of
> > authentication/authorization, create the Subject and let the EJB and
> > connector rely on that. The principal and roles are identical for Web
> > and EJB container.
> >
> 
> There are (at least) two pieces to the puzzle:
> 
> * How does a servlet container implement HTTP
>   BASIC (or DIGEST or whatever) authentication
>   at the protocol level (i.e. sending the right HTTP
>   headers and interpreting the responses).
> 
> * How does the servlet container know whether
>   the credentials presented by a particular user
>   are valid, and (by the way) what "roles" the now
>   authenticated user possesses.
> 
> The two issues are independent, and should be addressed independently:
> 
> * The mechanics of doing something like the
>   BASIC authentication protocol are generic,
>   no matter how you validate users.  It is appropriate
>   to implement this as a request interceptor (SecurityCheck
>   in Tomcat 3.x, SecurityValve in Catalina).
> 
> * The way that you validate a user is fairly generic,
>   no matter which authentication method (BASIC,
>   DIGEST, FORM) you choose for your web app.
>   It's not quite as clear cut because of things like
>  SSL, where you are tapping into a somewhat
>   different processing model.
> 
> So, what you'd like is a generic way for the request interceptor (or Valve) to say
> "here is a username and a password -- is it a valid combination?"  Thus, you need to
> define an internal-to-your-request-interceptor API by which that question is asked.
> As you point out, you don't want the security domain that answers the question to
> know anything about HTTP.  At the same time, you don't want your BASIC authentication
> implementation to care abou the differences between looking up users in a database,
> or a directory server, or whatever.  Thus, in design patterns terms, you want an
> "adapter" in between.  That's what a Realm interface really facilitates - the
> implementation adapts the BASIC authentication interceptor's view of the world (very
> HTTP-centric) to the security domain's view of the world (lots of variations in
> implementation).
> 
> The challenge, of course, is how do we standardize how much information from the
> incoming HTTP request is needed to perform the authentication.  Username and password
> (or username and a byte array of credentials) cover the simple cases -- it's not
> clear that they cover all of them.
> 
> Given that the customer of the Realm interface is in fact a Tomcat component (the
> authorization interceptor), it doesn't bother me that the Realm interface is Tomcat
> specific.  This does not at all imply that a Realm implementation must actually do
> all the work (although that's possible) -- in most cases it will simply delegate to
> some existing security domain implementation that really does the work.  For example,
> if you were integrating Tomcat inside a J2EE server, you'd simply adapt to the
> security domain stuff that already exists within that server, rather than
> re-inventing it from scracth.
> 
> How the delegation actually happens is a private decision of the Realm implementor,
> totally invisible to Tomcat's core servlet container.  Likewise, how Tomcat uses the
> answers to authentication questions (for example, send an HTTP "Not authorized"
> response) is invisible to the Realm implementation, and also therefore invisible to
> the underlying security domain.
> 
> >
> > arkin
> >
> 
> Craig
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org

-- 
----------------------------------------------------------------------
Assaf Arkin                                           www.exoffice.com
CTO, Exoffice Technologies, Inc.                        www.exolab.org

Re: authorization providers (was More on JAAS)

["Craig R. McClanahan" <Cr...@eng.sun.com>]

Arkin wrote:

> "Craig R. McClanahan" wrote:
> > In the case of Catalina's "Realm" interface, the only Tomcat dependency is on
> > the Container interface.  The rationale is this:  "Realm is an interface that a
> > security domain must implement to allow Tomcat to authenticate users and
> > validate roles."  Given that this is the whole point of Realm, it does not seem
> > like a problem to me -- plus, it allows the security domain to access other
> > resources of the container if needed.
>
> Which means a security provider has to be developed for Tomcat
> specifically and cannot be used for any other container.
>
> > Beyond that, it's not clear whether we can get away with just the current
> > authenticate() methods, or whether we might also (or instead) need:
> >
> >     public boolean authenticate(Request request);
> >
> > because we want to allow a realm implementation to access any request
> > properties it needs to.  This introduces one more dependency on the Tomcat
> > internals, but it's still a Tomcat internal API -- that's OK with me.
>
> In my opinion an authentication interceptor (Tomcat specific) should be
> used for that, not a generic security provider. A generic security
> provide has no notion of HTTP. In fact, it may be called at any point
> without any relation to an HTTP request.

> > Note:  a Realm implementation that itself uses JAAS (on a 1.3 platform)
> > certainly makes a lot of sense.  But it is not sufficient for many other cases
> > -- for example, a J2EE server with Tomcat embedded in it will have it's own
> > notion of users and roles for use by the EJB side, and you want the servlet
> > side to attach itself to that existing implementation.
>
> Actually the Servlet container would server as the point of
> authentication/authorization, create the Subject and let the EJB and
> connector rely on that. The principal and roles are identical for Web
> and EJB container.
>

There are (at least) two pieces to the puzzle:

* How does a servlet container implement HTTP
  BASIC (or DIGEST or whatever) authentication
  at the protocol level (i.e. sending the right HTTP
  headers and interpreting the responses).

* How does the servlet container know whether
  the credentials presented by a particular user
  are valid, and (by the way) what "roles" the now
  authenticated user possesses.

The two issues are independent, and should be addressed independently:

* The mechanics of doing something like the
  BASIC authentication protocol are generic,
  no matter how you validate users.  It is appropriate
  to implement this as a request interceptor (SecurityCheck
  in Tomcat 3.x, SecurityValve in Catalina).

* The way that you validate a user is fairly generic,
  no matter which authentication method (BASIC,
  DIGEST, FORM) you choose for your web app.
  It's not quite as clear cut because of things like
 SSL, where you are tapping into a somewhat
  different processing model.

So, what you'd like is a generic way for the request interceptor (or Valve) to say
"here is a username and a password -- is it a valid combination?"  Thus, you need to
define an internal-to-your-request-interceptor API by which that question is asked.
As you point out, you don't want the security domain that answers the question to
know anything about HTTP.  At the same time, you don't want your BASIC authentication
implementation to care abou the differences between looking up users in a database,
or a directory server, or whatever.  Thus, in design patterns terms, you want an
"adapter" in between.  That's what a Realm interface really facilitates - the
implementation adapts the BASIC authentication interceptor's view of the world (very
HTTP-centric) to the security domain's view of the world (lots of variations in
implementation).

The challenge, of course, is how do we standardize how much information from the
incoming HTTP request is needed to perform the authentication.  Username and password
(or username and a byte array of credentials) cover the simple cases -- it's not
clear that they cover all of them.

Given that the customer of the Realm interface is in fact a Tomcat component (the
authorization interceptor), it doesn't bother me that the Realm interface is Tomcat
specific.  This does not at all imply that a Realm implementation must actually do
all the work (although that's possible) -- in most cases it will simply delegate to
some existing security domain implementation that really does the work.  For example,
if you were integrating Tomcat inside a J2EE server, you'd simply adapt to the
security domain stuff that already exists within that server, rather than
re-inventing it from scracth.

How the delegation actually happens is a private decision of the Realm implementor,
totally invisible to Tomcat's core servlet container.  Likewise, how Tomcat uses the
answers to authentication questions (for example, send an HTTP "Not authorized"
response) is invisible to the Realm implementation, and also therefore invisible to
the underlying security domain.

>
> arkin
>

Craig

Re: authorization providers (was More on JAAS)

[Arkin <ar...@exoffice.com>]

"Craig R. McClanahan" wrote:
> In the case of Catalina's "Realm" interface, the only Tomcat dependency is on
> the Container interface.  The rationale is this:  "Realm is an interface that a
> security domain must implement to allow Tomcat to authenticate users and
> validate roles."  Given that this is the whole point of Realm, it does not seem
> like a problem to me -- plus, it allows the security domain to access other
> resources of the container if needed.

Which means a security provider has to be developed for Tomcat
specifically and cannot be used for any other container.

> Beyond that, it's not clear whether we can get away with just the current
> authenticate() methods, or whether we might also (or instead) need:
> 
>     public boolean authenticate(Request request);
> 
> because we want to allow a realm implementation to access any request
> properties it needs to.  This introduces one more dependency on the Tomcat
> internals, but it's still a Tomcat internal API -- that's OK with me.

In my opinion an authentication interceptor (Tomcat specific) should be
used for that, not a generic security provider. A generic security
provide has no notion of HTTP. In fact, it may be called at any point
without any relation to an HTTP request.


> Note:  a Realm implementation that itself uses JAAS (on a 1.3 platform)
> certainly makes a lot of sense.  But it is not sufficient for many other cases
> -- for example, a J2EE server with Tomcat embedded in it will have it's own
> notion of users and roles for use by the EJB side, and you want the servlet
> side to attach itself to that existing implementation.

Actually the Servlet container would server as the point of
authentication/authorization, create the Subject and let the EJB and
connector rely on that. The principal and roles are identical for Web
and EJB container.

arkin

> 
> Craig
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org

-- 
----------------------------------------------------------------------
Assaf Arkin                                           www.exoffice.com
CTO, Exoffice Technologies, Inc.                        www.exolab.org

Re: authorization providers (was More on JAAS)

["Craig R. McClanahan" <Cr...@eng.sun.com>]

Arkin wrote:

> Costin Manolache wrote:
> >
> > One question I have - is it possible to get the list of roles at
> > authentication time?  If that is true, there will be no need for
> > a callback. The callback may be needed only if the number
> > of roles is too big or the auth repository only allow "checkUserInRole",
> > not "getUserRoles" ( nothing is too paranoid in authentication systems).
>
> I would rather than the container not deal with either of that, but
> leave it to the authentication module to determine. Some modules will
> pick up the role list immediately, some will figure them out when
> isUserInRole() is called. Therefore, the container should call
> isUserInRole() on some interface, but never call getUserRoles().
>
> > I mostly agree with that - with the only exception that the set of
> > interfaces
> > should be independent of tomcat core or internals.
>
> +1 The interface should be security specific not container specific.
>

In the case of Catalina's "Realm" interface, the only Tomcat dependency is on
the Container interface.  The rationale is this:  "Realm is an interface that a
security domain must implement to allow Tomcat to authenticate users and
validate roles."  Given that this is the whole point of Realm, it does not seem
like a problem to me -- plus, it allows the security domain to access other
resources of the container if needed.

Beyond that, it's not clear whether we can get away with just the current
authenticate() methods, or whether we might also (or instead) need:

    public boolean authenticate(Request request);

because we want to allow a realm implementation to access any request
properties it needs to.  This introduces one more dependency on the Tomcat
internals, but it's still a Tomcat internal API -- that's OK with me.

Note:  a Realm implementation that itself uses JAAS (on a 1.3 platform)
certainly makes a lot of sense.  But it is not sufficient for many other cases
-- for example, a J2EE server with Tomcat embedded in it will have it's own
notion of users and roles for use by the EJB side, and you want the servlet
side to attach itself to that existing implementation.

Craig

Re: authorization providers (was More on JAAS)

[Costin Manolache <co...@costin.dnt.ro>]

> To be more generic, a container is a container is a container. It could
> be a Servlet container, or it could be a Mailet or Phonelet or EJB or
> any other form of container. Tomcat is one such container.
>
> The container authenticates the user against a login module. (Whether
> you use JAAS or a different API, the semantics are generally the same)
> The container authenticates using some security provider API. JAAS is
> one such API. Apache modules is another API.
>
> Some forms of authentication are active (i.e. container goes to module
> and say please authenticate 'Joe'/'secret') others are passive (i.e.
> container gets prior authentication).

That's exactly what I think too. And while JAAS is not an option yet - we
should stay close to the idea and concepts inside - unless we have strong
reasons to think we can abstract the authentication in a better way. That's
why I think tomcat should only bridge between the HTTP request and a
real authentication API.

Costin

Re: authorization providers (was More on JAAS)

[Arkin <ar...@exoffice.com>]

Costin Manolache wrote:
> 
> > > > 1. We define a set of interfaces for a J2EE principal and roles
> > > > credentials and a way to authenticate given no user, user/password,
> > > > user/certificate, cookie. The container only uses these interfaces.
> > >
> > > The container will use these interfaces in most cases - "only" is too
> > > strong :-)
> >
> > "Only" as in, if the container makes a request to a login module for the
> > purpose of J2EE authentication & authorization it will use just these
> > interfaces and no other extensions. If the container talks to someone
> > else for any other purpose (say just authentication) it can use any
> > other interface that makes sense, however, that is a container issue and
> > a generic authentication module is not aware of that.
> 
> > > ( and tomcat will use the apache modules if it runs in "integrated"
> > > mode - the java interfaces will not be called in this case )
> >
> > +1 In which case the container needs some other way to authenticate.
> 
> I'm a bit confused - who is the container?  I thought tomcat is the servlet
> container.

Tomcat.

To be more generic, a container is a container is a container. It could
be a Servlet container, or it could be a Mailet or Phonelet or EJB or
any other form of container. Tomcat is one such container.

The container authenticates the user against a login module. (Whether
you use JAAS or a different API, the semantics are generally the same)
The container authenticates using some security provider API. JAAS is
one such API. Apache modules is another API.

Some forms of authentication are active (i.e. container goes to module
and say please authenticate 'Joe'/'secret') others are passive (i.e.
container gets prior authentication).

arkin


> 
> Costin
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org

-- 
----------------------------------------------------------------------
Assaf Arkin                                           www.exoffice.com
CTO, Exoffice Technologies, Inc.                        www.exolab.org

Re: authorization providers (was More on JAAS)

[Costin Manolache <co...@costin.dnt.ro>]

> > > 1. We define a set of interfaces for a J2EE principal and roles
> > > credentials and a way to authenticate given no user, user/password,
> > > user/certificate, cookie. The container only uses these interfaces.
> >
> > The container will use these interfaces in most cases - "only" is too
> > strong :-)
>
> "Only" as in, if the container makes a request to a login module for the
> purpose of J2EE authentication & authorization it will use just these
> interfaces and no other extensions. If the container talks to someone
> else for any other purpose (say just authentication) it can use any
> other interface that makes sense, however, that is a container issue and
> a generic authentication module is not aware of that.

> > ( and tomcat will use the apache modules if it runs in "integrated"
> > mode - the java interfaces will not be called in this case )
>
> +1 In which case the container needs some other way to authenticate.

I'm a bit confused - who is the container?  I thought tomcat is the servlet
container.



Costin

Re: authorization providers (was More on JAAS)

[Arkin <ar...@exoffice.com>]

Costin Manolache wrote:
> 
> One question I have - is it possible to get the list of roles at
> authentication time?  If that is true, there will be no need for
> a callback. The callback may be needed only if the number
> of roles is too big or the auth repository only allow "checkUserInRole",
> not "getUserRoles" ( nothing is too paranoid in authentication systems).

I would rather than the container not deal with either of that, but
leave it to the authentication module to determine. Some modules will
pick up the role list immediately, some will figure them out when
isUserInRole() is called. Therefore, the container should call
isUserInRole() on some interface, but never call getUserRoles().


> I mostly agree with that - with the only exception that the set of
> interfaces
> should be independent of tomcat core or internals.

+1 The interface should be security specific not container specific.

> For example Realm depends on a number of internal interfaces in Catalina,
> and ReqSecurityProvider depends on tomcat.core.
> 
> We can add a tomcat.security package and define our favorite set of
> authentication interfaces. It will work both in Catalina, tomcat, or any
> other
> system ( sort of mini-JAAS). It's important to keep it independent - not
> only
> for reuse, but also as design. After all - authentication is a serious
> subject,
> not just a small piece of tomcat.
> 
> We add interceptors for tomcat.security- that is not very hard, and after
> it's done there is no need to argue.
> We add interceptors for JAAS - there is no point in adding an extra layer
> on front of JAAS.
> 
> > 1. We define a set of interfaces for a J2EE principal and roles
> > credentials and a way to authenticate given no user, user/password,
> > user/certificate, cookie. The container only uses these interfaces.
> 
> The container will use these interfaces in most cases - "only" is too
> strong :-)

"Only" as in, if the container makes a request to a login module for the
purpose of J2EE authentication & authorization it will use just these
interfaces and no other extensions. If the container talks to someone
else for any other purpose (say just authentication) it can use any
other interface that makes sense, however, that is a container issue and
a generic authentication module is not aware of that.

> ( and tomcat will use the apache modules if it runs in "integrated"
> mode - the java interfaces will not be called in this case )

+1 In which case the container needs some other way to authenticate.

arkin


> 
> > 2. An implementation can run directly in the container supporting just
> > these interfaces.
> 
> +1
> 
> > 3. An implementation can use JAAS to talk to other login modules that
> > use these (or other) interfaces and is responsible for all conversions
> > (e.g. user/password to UserPasswordCredentials)
> 
> +1
> 
> Costin
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org

-- 
----------------------------------------------------------------------
Assaf Arkin                                           www.exoffice.com
CTO, Exoffice Technologies, Inc.                        www.exolab.org

Re: authorization providers (was More on JAAS)

[Costin Manolache <co...@costin.dnt.ro>]

One question I have - is it possible to get the list of roles at
authentication time?  If that is true, there will be no need for
a callback. The callback may be needed only if the number
of roles is too big or the auth repository only allow "checkUserInRole",
not "getUserRoles" ( nothing is too paranoid in authentication systems).


> How about the following, and I think this would be the best short-term,
> long-term solution:

I mostly agree with that - with the only exception that the set of
interfaces
should be independent of tomcat core or internals.
For example Realm depends on a number of internal interfaces in Catalina,
and ReqSecurityProvider depends on tomcat.core.

We can add a tomcat.security package and define our favorite set of
authentication interfaces. It will work both in Catalina, tomcat, or any
other
system ( sort of mini-JAAS). It's important to keep it independent - not
only
for reuse, but also as design. After all - authentication is a serious
subject,
not just a small piece of tomcat.

We add interceptors for tomcat.security- that is not very hard, and after
it's done there is no need to argue.
We add interceptors for JAAS - there is no point in adding an extra layer
on front of JAAS.


> 1. We define a set of interfaces for a J2EE principal and roles
> credentials and a way to authenticate given no user, user/password,
> user/certificate, cookie. The container only uses these interfaces.

The container will use these interfaces in most cases - "only" is too
strong :-)
( and tomcat will use the apache modules if it runs in "integrated"
mode - the java interfaces will not be called in this case )


> 2. An implementation can run directly in the container supporting just
> these interfaces.

+1

> 3. An implementation can use JAAS to talk to other login modules that
> use these (or other) interfaces and is responsible for all conversions
> (e.g. user/password to UserPasswordCredentials)

+1

Costin

Re: authorization providers (was More on JAAS)

[Arkin <ar...@exoffice.com>]

mark@mjwilcox.com wrote:
> For my current example I'm using groups (either groupOfnames or
> groupOfUniquenames).  I map the role name to the group's
> common name.

+1

> > In our case we have a role entry in a given DN space
> > (uid=...,ou=Roles,...) which lists the users under that role (by DN).
> This is essentially what an LDAP group is.

Yep. We use groupOfNames as the objectclass, and the DN path is
configurable, but we tend to use ou=Roles for J2EE roles.


> I prefer the dynamic group to this route. A dynamic group is a
> groupOfUrls object which stores its members as LDAP queries in
> the form of LDAP URLs.
> 
> A user is a member of the group if their entry would satisify one of
> the LDAP queries. This allows you to have infinitely large groups.
> People also come and go out of the groups as their inividual entries
> are updated, you don't have to update one or more secondary
> group objects.

I didn't know there's a standard way of doing that. I like it.


> You just can't load everything into memory because that could be
> quite large. I easily have over 6000 groups with over a total of
> 25,000+ users (I use groups to manage class roles at our
> university). I'd rather just query the LDAP server when necessary
> and not use memory unecessarily.

I expected the 'roles' list to be fairly small and depend not on the
number of users but on the number of different roles, so a typical
application can be 5 to 40 roles, and actually the smaller the user base
is the larger the role list is. For Internet usually all users fall in
two/three roles, while for Intranet you have a variety of roles.

But I understand your model, which is why I recommend that the login
module hand back a generic interface calls RolesCredentials that
supports isInRole(). One implementation (works in my case) would
populate all the roles during authentication. Another implementation
(works in your case) would keep the LDAP connection properties and
user's DN and make queries to the LDAP server each time it needs to. The
Mozilla SDK would come handy in this case since it supports connection
pooling that your implementation can configure.


> Probably true, but I still think JAAS is a future thing not a current
> thing. We can document how people should do this but I don't think
> we can make it a requirement.

How about the following, and I think this would be the best short-term,
long-term solution:

1. We define a set of interfaces for a J2EE principal and roles
credentials and a way to authenticate given no user, user/password,
user/certificate, cookie. The container only uses these interfaces.

2. An implementation can run directly in the container supporting just
these interfaces.

3. An implementation can use JAAS to talk to other login modules that
use these (or other) interfaces and is responsible for all conversions
(e.g. user/password to UserPasswordCredentials)

For now, since 2 is definitely working and 3 is so so, I would recommend
using no. 2, but keeping a design pattern that allows us to optionally
switch to 3. And I use optionally because even some users will rather
use JAAS, some would not change what is working, so expect no. 2 to be
supported way into the future.

arkin


> 
> mark
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org

-- 
----------------------------------------------------------------------
Assaf Arkin                                           www.exoffice.com
CTO, Exoffice Technologies, Inc.                        www.exolab.org

Re: authorization providers (was More on JAAS)

[ma...@mjwilcox.com]

On 17 Apr 00, at 22:01, Assaf Arkin wrote:


> > 3) we should be able to populate the Roles object
> > While I can authorize a user per role (e.g. LDAP group), I cannot
> > set the Roles value for when someone wants that information from
> > request.getRoles().
> 
> Out of curiosity how do you map a user into roles?
>
For my current example I'm using groups (either groupOfnames or 
groupOfUniquenames).  I map the role name to the group's 
common name. 

For 'real' I'd add in support for groups to be members of other 
groups and also support for Netscape/iPlanet Dynamic groups. 

If I could figure out how to declare it in Tomcat, I'd also throw in 
support for using LDAP URL queries.

For a better idea of what I'm talking about you can glance at my 
Apache modules at http://courses.unt.edu/mewilcox/.

I also have an article in the May issue of Web Techniques, though I 
did the article in Perl, but the ideas apply to LDAP in general.




> In our case we have a role entry in a given DN space
> (uid=...,ou=Roles,...) which lists the users under that role (by DN). 
This is essentially what an LDAP group is.

We
> pre-load the roles into memory (doesn't take that much space) and we
> determine the roles for a user when the user authenticates. To deal with
> mass quantity of users we use mapping of roles to directories of users
> and default roles.
I prefer the dynamic group to this route. A dynamic group is a 
groupOfUrls object which stores its members as LDAP queries in 
the form of LDAP URLs.

A user is a member of the group if their entry would satisify one of 
the LDAP queries. This allows you to have infinitely large groups. 
People also come and go out of the groups as their inividual entries 
are updated, you don't have to update one or more secondary 
group objects.

You just can't load everything into memory because that could be 
quite large. I easily have over 6000 groups with over a total of 
25,000+ users (I use groups to manage class roles at our 
university). I'd rather just query the LDAP server when necessary 
and not use memory unecessarily.



> 
> > The only item I really lacked was the ability to populate the roles
> > as I said before. This could be fixed in the Security Interceptor by
> > populating a hashtable or map that was updated on each call to
> > userInRole and then passed onto the Request object.
> 
> JAAS would probably define that as a RoleCredential which you can ask
> isInRole(). The RoleCredential is placed in the Subject (the security
> context) by the login module, so the login module can place a
> fully-loaded object, or a lazy-loading object.

Probably true, but I still think JAAS is a future thing not a current 
thing. We can document how people should do this but I don't think 
we can make it a requirement.

mark

Re: authorization providers (was More on JAAS)

[Assaf Arkin <ar...@exoffice.com>]

> 1) First people should be able freely write security interceptors as
> they see fit.

+1

> 3) we should be able to populate the Roles object
> While I can authorize a user per role (e.g. LDAP group), I cannot
> set the Roles value for when someone wants that information from
> request.getRoles().

Out of curiosity how do you map a user into roles?

In our case we have a role entry in a given DN space
(uid=...,ou=Roles,...) which lists the users under that role (by DN). We
pre-load the roles into memory (doesn't take that much space) and we
determine the roles for a user when the user authenticates. To deal with
mass quantity of users we use mapping of roles to directories of users
and default roles.

> The only item I really lacked was the ability to populate the roles
> as I said before. This could be fixed in the Security Interceptor by
> populating a hashtable or map that was updated on each call to
> userInRole and then passed onto the Request object.

JAAS would probably define that as a RoleCredential which you can ask
isInRole(). The RoleCredential is placed in the Subject (the security
context) by the login module, so the login module can place a
fully-loaded object, or a lazy-loading object.


> But what about X.509 or kerberos? I think perhaps we can solve
> that adding 2 more signatures to the checkPassword and
> userInRole.

You would put some credential object (X509Credential, KerberosTicket)
inside Subject before authenticating, and the login modules can grab
that object and use it for authentication if they support it.

Of you could have JAAS callbacks, but I hate those.

arkin

> Instead of taking username and passwords they could take either
> an array of bytes or a generic Object. The SecurityInterceptor
> would only call these versions of the methods if the method of
> authentication/authorization was not BASIC,DIGEST or FORM.
> 
> I'm not exactly sure how to handle multiple interceptors yet.
> 
> The actual implementors of the interceptors could use whatever
> mechanism they wished (JNDI, JAAS, Kerberos, etc) as long as
> they extended the proper class.
> 
> The default provider would simply implement this API. We could
> then provide extras if we wanted that people could optionally
> compile and add in, just like you can with Apache.
> 
> I'm under a tight deadline right now to finish my chapter that started
> all of this. I'll try to get at least my source code published to the
> Web this week (if people want me to submit it to Tomcat, I can, but
> I'd rather wait until this is settled).
> 
> Mark
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org

Re: When 3.1. final comes to us?

[Hans Bergsten <ha...@gefionsoftware.com>]

"Alexey V. Meledin" wrote:
> 
> Hi,
>  tomcat-developers!
> 
>  In tomcat developers plan I see the 7/04.
>  Lastest binary version is dated by 27 march, but there is 19 april.

It was release today. The following message was sent to the Tomcat
general list:


Subject: Announcing release 3.1 of Tomcat!

Download it at http://jakarta.apache.org/builds/tomcat/release/v3.1/

In addition to continuing to supporting the latest Java Servlet and
JavaServer Pages Specifications, this release contains a number of
improvements over the Tomcat 3.0 release:

 * Thread pooling and JVM load balancing
 * ISAPI and NSAPI integration
 * A Command line JSP to Servlet Code tool
 * Automatic generation of Apache configuration files
 * Automatic deployment of Web ARchive (WAR) files
 * Logging
 * Substantially improved documentation
 * Experimental servlet reloading
 * Experimental security implementation
 * Minimal Admin/Deployment Tool
 * Internal APIs were changed for flexibility and integration
 * The source code was cleaned and reorganized
 * Most non-essential code was moved out of tomcat.core
 * Greater platform / JVM level coverage
 * Many, many bugs were fixed.

- Sam Ruby




-- 
Hans Bergsten		hans@gefionsoftware.com
Gefion Software		http://www.gefionsoftware.com

When 3.1. final comes to us?

["Alexey V. Meledin" <av...@webclub.ru>]

Hi,
 tomcat-developers!

 In tomcat developers plan I see the 7/04.
 Lastest binary version is dated by 27 march, but there is 19 april.
 
Alexey V. Meledin <av...@webclub.ru>
> InterForge Developers Group,  St-Petersburg, Russia
New: http://www.crossroad.ru; http://www.garoway.com
> > > > > > "InterForge to Forge Ahead" > > > > > > >

Re: authorization providers (was More on JAAS)

[Brill Pappin <br...@jmonkey.com>]

FYI-
I'm getting two new build arrors from ant, when building Tomcat... They
happen with a clean build of ant and tomcat updated today (18-APR-200
13:14).
The errors follow:

C:\working\jakarta-tomcat\src\share\org\apache\tomcat\service\connector\Door
Conn
ectionHandler.java:130: Wrong number of arguments in constructor.
            ConnectorResponse rresponse=new ConnectorResponse(con);
                                        ^
C:\working\jakarta-tomcat\src\share\org\apache\tomcat\service\connector\Door
Conn
ectionHandler.java:131: Wrong number of arguments in constructor.
            ConnectorRequest  reqA=new ConnectorRequest(con);

Re: authorization providers (was More on JAAS)

[Costin Manolache <co...@costin.dnt.ro>]

> > - How do you plan to integrate between web-server-based authentication
> > and tomcat ? ( static files are served by the web server ).
>
> Two different approaches are feasible:
> * A Realm implementation that directly reads the same files, or
> * A Realm implementation that knows it's running with a web server
>   connector and uses the proprietary webserver-Tomcat protocol to
>   ask the questions it needs.
>
> In other words, its exactly the same amount of new code you would add in a subclass
> of SecurityCheck to do the same thing.

First is not an option - most Apache realms are not text file based ( at least DBM,
or LDAP, NIS, etc).
Second - most adapters are not bidirectional ( at least the stable one is not ), and it
adds
one ( or several ) round-trips to the server. And more important - Apache does
_not_ provide an API for authentication !!!!!
( neither NES or IIS as far as I know ). You just _can't_ ask apache to verify a
user and pasword or tell you what are the roles.

You can just let the authentication module in apache do it's job - and in this case
you don't even need a SecurityCheck.
Of course, same would be possible with Realm ( set up tomcat to not use
Realm, and let apache do the auth ) - but if you declare an interface people
will expect it to work, and the contracts to be respected.

With SecurityCheck - the only contract is that during the request processing
we will verify the user. No promises or exposed APIs ( when none is available).


> > - How can you implement "trust only users from a certain IP domain ( a very valid
> > and common security restriction )"?
> >
>
> Even easier (and doesn't require a Realm) - a Valve that looks at the value returned
> by getRemoteAddr() or getRemoteHost() and applies the filters you've configured.  One
> thing Valves can do that RequestInterceptors cannot is to handle the request and
> return (in this case, the IP filter Valve would return
> HttpServletResponse.SC_FORBIDDEN), instead of passing the request on to the rest of
> the engine - in particular, no Valve or Container after this filter would even see
> requests from invalid IP domains.  You'd undoubtedly deploy this Valve earlier in the
> request processing pipeline than the security check, to avoid wasting the time to
> look up a user you're not going to accept anyway because of the IP address filtering.

First - it's not true that RequestInterceptors can't handle the request - it just have to

set the handler. And yes, that's a solution - but what happens with Realm ? The
authentication
is done in a Valve here ( which is similar with RequestInterceptor - at least at the same

level ), in the adapter in the previous case - where do you use Realm then ?

If integrated with apache/IIS/NES -> web does the authentication ( required because
static
files need the same auth ), no Realm

If JAAS is used -> JAAS is a more powerfull interface and I hope people will use the
"real" thing if available ( and the only limitation is the JDK version - long term we
can expect the standard to win ).

If complex authentication rules are in place ( i.e anything more than user/pass) -> you
need
the valve or request interceptor

Even for LDAP auth - people will probably use JNDI or another toolkit, why add another
layer between the request processing and the data source ? ( given that LDAP may allow
complex conditions - we are back to previous case )



> > And most important question:
> >
> > Why use an interface that doesn't provide you anything that is not already
> > available, but reduce the flexibility and add complexity ?
> >
>
> As Stefano would say :-), the issue is "separation of concerns".  The fundamental
> design issue that Catalina changes vs. Tomcat 3.x (in respect to security) is a
> separation between the following concepts:

That's exactly what the interceptor does - except that it doesn't impose a specific
API for user lookup. Creating an authentication API is not easy - and ( as seen in
JAAS) may take more than 2 methods. If the issue is "separation of concerns" -
then we should be concerned about processing the request and let security
exeperts design authentication APIs. ( and maybe use what exists instead of
creating yet-another-interface)

> * How do you implement request.isUserInRole()?  (This was Mark's
>   comment that sparked the current discussion).  Currently, there's
>   no way for the request implementation to "get to" the underlying
>   realm you've loaded into the interceptor.  The proposed solution
>   is to add yet another method callback to the 9 or 10 already there
>   in RequestInterceptor.  Like most of the other ones, this is only
>   needed to get around the fact that the two concepts above are
>   combined instead of separated.

The reason you need that - is to deal with the fact that the world is not
under our control !
Yes, it would be nice to just add Realm and say that we support
authentication sources that implment Realm - but in real world
you need a bit more.

It also allow cooperation between multiple security providers -
like in PAM.



> * What happens when another authentication method is added in
>   some future version of the servlet API?  The current architecture
>   forces you to add it to SecurityCheck (plus side effects on at least
>   three other source modules, instead of being able to do everything
>   in one place).  With Catalina, you can do that all in a single class,
>   or define a separate Valve for each type of authentication that is
>   installed when you read web.xml to see what is necessary.  And,
>   you can mix and match any authentication method with any Realm
>   implementation -- they don't have a common subclass, so they
>   can be developed and deployed independently.

SecurityCheck is just an example implementation - and normal
OO methods can still be used ( extend, use, etc). It's just that we try
to impose the minimal set of contracts and rules - and allow more
flexibility.

Any decent implementation of SecurityCheck ( integrated with JAAS,
LDAP, etc) will probably use a number of classes - since this is the
first implementation I don't think we have enough information and
experience to require a specific model or structure.



> Finally, it's amusing to note that this doesn't really add a new kind of object :-).
> We already have a MemoryRealm object with similar characteristics -- it's just hidden
> inside SecurityCheck (as a private class) instead of being public where it is more
> useful.

Yes - the MemoryRealm is just _one_ way to deal with that, and it's not part
of core and hidden to not let people believe that's the best solution. In fact, it's
probably a solution only in simple cases.

Even SecurityCheck is just one possible implementation, that can be reused
or just used as a start - but it's far from an interface.


> > What is missing in the current model? It seems all web servers ( IIS, Nes, Apache
> > at least) are doing fine with the filter/SAF/module model.
> >
>
> One particular thing that's missing is a way to implement isUserInRole() without
> adding another callback.

It seems Realm also requires a callback for isUserInRole() ( except that it's hidden
in the implementation ). In most cases it is not even needed, since the roles can
be set up on authentication.



> On a larger scale, and as we will discuss more, I'm sure, Tomcat is not a web server
> -- that problem has been solved quite nicely, thank you.  Instead, it is a container
> for web based applications, which do not necessarily have the same requirements for
> functionality (or even the same sweet spots for performance optimizations).

That's exactly my point - tomcat is not a web server, it's a container for  web-based
applications - it needs a web server to work ( even if it's the simple http/1.0 java
adapter we use ).


> Doing things in Tomcat "just because web servers do them that way" is not a
> sufficient argument, without understanding the costs imposed by that design.  (For
> example, have you counted the number of empty method calls the current Interceptor
> design causes to happen on every request?  They are fairly cheap, but they are
> definitely not free.)

That's why getMethods() exists. It's not implemented, but it allows just that.
See the FILTER_VERSION flags in IIS, SAF config in NES and the hooks in
apache - same model.

Regarding costs - I suppose using an unproven model ( just because it may look
better on paper) is more costly.


> > Yes - the interceptor is not supposed to implement authentication lookups, but to
> > _use_ a component. With the difference that the authentication component is not
> > imposed by tomcat, but it's anything you want, with any interface. It needs to be
> > in its own component - but the component is not under our control, we should use
> > existing systems where possible.
> >
>
> The *interface* to the component is being defined (that's what Realm is for) so you
> can plug in the implementation you want.  This interface defines only what Tomcat
> needs to satisfy its questions ("is this user authenticated?"  "is this user in this
> role?").  Realm does not impose any restrictions on *how* those questions are
> answered.

Same is true for interceptor - just at a different level, and without adding a new
interface.


> As mentioned above, you've already done exactly the same thing inside SecurityCheck
> -- it's just hidden, so it's not useful quite everywhere it needs to be.  I'm
> proposing that people be able to implement realms independent of messing with
> SecurityCheck.

And I'm proposing that people be able to implement realms in JAAS or any
public authentication interface that is out there. They can reuse the code in
SecurityCheck or create a new interceptor - if people are using IIS/NES/Apache
they can and should just use the _existing_ interceptor.

In fact - it's a non-problem for most production environments. I suppose any
real web site has already a security system in place, and they probably have
apache modules to use it. So in most cases you don't need anything on the
tomcat side.  SecurityCheck is usefull just for simple web servers that have
no authentication or standalone tomcat.

Costin

Re: authorization providers (was More on JAAS)

["Craig R. McClanahan" <Cr...@eng.sun.com>]

Costin Manolache wrote:

> Mark,
>
> > I'm all for discussion. After all this is rather groundbreaking stuff.
> > While 'tis true that all of the popular Web servers use a filter model
> > similar to our interceptor model, they also all use C to write their
> > servers. (IIS may use C++, but if it follows MS tradition that is just
> > C++ wrappers around straight C code like the Windows API).
>
> You can modules in Perl too. And soon - I hope - you'll be able to
> write modules in Java !
>

+1 for that.

Once upon a time, the Apache JServ project started a "MOD_JAVA" subproject
(Costin was one of the instigators).  It kind of died for lack of interest and
time.  This would be a good thing to resurrect.  There are some notes at the web
site <http://java.apache.org> and the mail archives.

One of the places that this initial effort could be improved, IMHO, is to design
the Java API for modules to be as close as feasible to the Apache module design
-- very similar, in fact, to the current RequestInterceptor design in Tomcat 3.x
-- but without trying to turn it into "servlet" requests.  That's just overhead
from the perspective of a module API.

I would also have no problems with such a MOD_JAVA subproject (jakarta-modjava?)
started under Jakarta.

Craig

Re: authorization providers (was More on JAAS)

[Costin Manolache <co...@costin.dnt.ro>]

"Craig R. McClanahan" wrote:

> Costin Manolache wrote:
>
> > > I know about Perl (that's the day job ;) and Apache. There's also a
> > > simplistic Perl api for Netscape and I think you can do something
> > > in IIS, but the point is that even with Perl, the underlying
> > > architecture is still primarily derived because the server itself is in C.
> >
> > I'm curious - where do you think is the impact of C in this architecture?
> > My impresion is that what matter most is the alghoritm - not the
> > language you use to express it.
> >
>
> It matters because design patterns copied from C sometimes have performance
> impacts when you transliterate them to Java.

I would argue that "design patterns" are language independent - in this particular
case it's probably a "Chain of Responsability" pattern, with a bit of "Strategy".
Implementation of those strategies in C and Java may differ - but still there is
not C that is the reason for this pattern !

Apache 2.0 is even closer to those patterns ( with hooks ).


> Consider the current RequestInterceptor interface, with roughly 10 "handler"
> methods.  In C, it is pretty low overhead to maintain a dispatch table of
> pointers to functions, and just call the ones that are non-NULL (i.e. the ones
> that the module has registered itself as interested in).  In Java, all 10 of
> those calls happen on *every* interceptor (assuming they flow on through, which
> is the usual case), on *every* request.  Most of them just use the empty
> impelmentation in the default base class -- they are relatively cheap, but they
> are definitely NOT free.

As I said earlier - the RequestInterceptor _interface_ is fine - it provides
getMethod() that should return the  "chains of responsibility" the interceptor
is interested in, and only those methods will be included in the dispatch
table for that particular event.

The implementation is not done - it was better to spend time in other areas, and
the impact of not having that implemented is not bad. The design is fine.

There is a problem with the current interceptor - the fact that it's hard to
extend it ( you have to add a new method ) - but that's a choice that I still think

 was right. The main reason for that was to keep a familiar and simple interface.
The alternative is to do something like the hooks in apache - but I felt
that for now it's better to keep it simpler. There is no problem implementing
_both_  - the behavior is the same and the 2 concepts are inter-changeable,
but I would rather wait with that till it's really needed.

( in fact my hope is to combine hooks with another very important java-only
implementation - CharBuffers, to reduce the String GC. If we do that it will
make sense to do this big step). Java is great because we can support multiple
implementations of the pattern and provide backward compatibility - which
is harder on C.


> In comparison, the Catalina architecture for Valves requires one method call per
> interceptor -- to the invoke() method -- no matter how complex its internel
> logic is.  There are other differences that I want to address in the context of
> a response to one of Gal's questions; this will be in a separate message.

As I explained - it is possible to have one call per interceptor if there is only
one interceptor ( from  Strategy point of view) for that operation.

On the other side - Valve implements a completely different alghoritm and pattern-
it divides the problem into smaller problems. I.e.

processing a request == extract the context + process context mapping.

One Valve will implement the first step, and a second one will split "process
ctx mapping" in "extract servlet path + call servlet wrapper  container".

There are a lot of fundamental problems with this - one is that it
impose a certain parsing/matching alghoritm that is not the most
efficient.  What's worse - it does this at the object-model level.
Another big problem - from all the web-server experience, it
seems Chain of Responsability _is_ important - it allows use
of different althoritms and more flexibility.

Authentication is just one particular case of this...

Costin

Re: authorization providers (was More on JAAS)

["Craig R. McClanahan" <Cr...@eng.sun.com>]

Costin Manolache wrote:

> > I know about Perl (that's the day job ;) and Apache. There's also a
> > simplistic Perl api for Netscape and I think you can do something
> > in IIS, but the point is that even with Perl, the underlying
> > architecture is still primarily derived because the server itself is in C.
>
> I'm curious - where do you think is the impact of C in this architecture?
> My impresion is that what matter most is the alghoritm - not the
> language you use to express it.
>

It matters because design patterns copied from C sometimes have performance
impacts when you transliterate them to Java.

Consider the current RequestInterceptor interface, with roughly 10 "handler"
methods.  In C, it is pretty low overhead to maintain a dispatch table of
pointers to functions, and just call the ones that are non-NULL (i.e. the ones
that the module has registered itself as interested in).  In Java, all 10 of
those calls happen on *every* interceptor (assuming they flow on through, which
is the usual case), on *every* request.  Most of them just use the empty
impelmentation in the default base class -- they are relatively cheap, but they
are definitely NOT free.

In comparison, the Catalina architecture for Valves requires one method call per
interceptor -- to the invoke() method -- no matter how complex its internel
logic is.  There are other differences that I want to address in the context of
a response to one of Gal's questions; this will be in a separate message.

Re: authorization providers (was More on JAAS)

[Costin Manolache <co...@costin.dnt.ro>]

> > > I'm all for discussion. After all this is rather groundbreaking stuff.
> > > While 'tis true that all of the popular Web servers use a filter model
> > > similar to our interceptor model, they also all use C to write their
> > > servers. (IIS may use C++, but if it follows MS tradition that is just
> > > C++ wrappers around straight C code like the Windows API).
> >
> > You can modules in Perl too. And soon - I hope - you'll be able to
> > write modules in Java !
> I know about Perl (that's the day job ;) and Apache. There's also a
> simplistic Perl api for Netscape and I think you can do something
> in IIS, but the point is that even with Perl, the underlying
> architecture is still primarily derived because the server itself is in C.

I'm curious - where do you think is the impact of C in this architecture?
My impresion is that what matter most is the alghoritm - not the
language you use to express it.


> > I'm interested to hear how much processing is part of the critical path,
> > how and what alghoritms and data structures can we use to implement
> > the parsing and searching, and how can we reuse existing code.
> >
> I agree. I think that we're concentrating so much on particular
> issues we're missing the bigger picture (e.g. missing the forest for
> the trees).

We're missing both the forest and the trees, and a lot of time :-)


> > If we discuss about authentication - I'm interested how can we address
> > existing systems ( like apache + any auth module). In a controled
> > environment everything works fine and looks flexible.
> >
> I think we handle communication with the Web server via the
> protocol.

Well - look at the trees too : a round-trip to the web server is _very_
expensive. Sure - with 3 users it will not show up, but what will happen
with 100 ?

Costin

Re: authorization providers (was More on JAAS)

[Arkin <ar...@exoffice.com>]

> This still requires a callback somewhere to populate the roles. (or
> does it? I thought perhaps SecurityCheck could call isUserInRole
> and if true add the role to the request, if not, remove or don't add
> the role)


My understanding, the role list should be available form some interface
(let's call it RolesCredential for now) and the container can call
isInRole() any number of times in any order. That defines that the role
list is always "loaded" from the container's perspective.

An implementation may load all roles at once when constructing a
RolesCredential, or it may load them lazily (e.g. by keeping an open
connection to the LDAP server), or it may otherwise obtain them (e.g.
from an independent role-enlistment cache).

The callback is not the responsibility of the container or the
interceptor, it's the responsiblity of the authorization module that
returns a RolesCredential.

BTW the following is unspecified, but is desired behavior. The roles to
which a user belongs are determined when the authentication happens,
once authenticated the list of roles will never change even if roles are
lazily loaded. Any deviation from that can cause conflicts when the
application consists of other mechanisms (EJB, connectors, Kerberos)
that might depend on roles.

arkin



> >
> > What model for request processing do you prefer ?
> >
> > My personal preference is to use Event and EventListeners -
> > they have a simpler design and resolve the same problem.
> > Maybe one day I'll just implement that as a revolution,
> > with a lot more care for GC.
> > But I'm not sure it is "better" - and I'll not be sure until
> > I have a prototype and I can compare it and see how it works
> > in real world.
> 
> Actually that's what I've been thinking as well. That perhaps we
> have an AuthenticateEvent and AuthorizationEvent. I'm still thinking
> on what would make this up (e.g. what gets passed to what).
> 
> Though I think you need the events to be a two-way street.
> 
> >
> > Web servers have a long history and a lot of smart developers,
> > and this model seems to work - and it was more than used in
> > all those years. I need more than words to use something
> > out of whiteboards.
> I agree completely. That's why I think perhaps for 3.x we should
> just get something to work. We're already pretty close in terms
> that we can replace the SecurityInterceptor with something and
> authenticate & even authorize a user with a userid & password.
> 
> If we can figure the quickest way to get roles popluated, then I
> think we'll be rather set. I'd be happy to add in the callbacks if
> someone can at least tell me where I need to put in the hooks.
> 
> Then for 4 we can get something better in place. This is sort of like
> Apache. 1.3.x was make it work. 2.0 is how to make it work now
> knowing what we know.
> 
> All of this stuff is just so new, I don't think we know enough really
> to say yea or ney on much of anything (in particular since we've
> only dealt with the theoretical so far ;).
> 
> I'd also be happy to tackle the event issue, though that's going to
> be a while (most likely) since that's not an area I'm real familiar
> with and I'm committed to several projects in May (though after
> May, I'm pretty free).
> >
> 
> > > So while I agree Tomcat will/shouldn't replace the everyday
> > > workhorse Web servers, there are areas where it likely will fill in
> > > where we cannot see (if you can, make sure you have access to
> > > some VC because you'll likely cash in big).
> >
> > If we expect people to use servlets/jsp instead or in addition to
> > mod_perl/php/asp we should be able to run in similar conditions
> > with similar speed. If the response time is more than 2 seconds -
> > nobody cares that your software can also run from a toaster. If you can't
> > use the same authentication as the rest of your applications -
> > nobody cares that you have plugeable  APIs or original architecture.
> Yes, I just had to wait several seconds for my JSP to compile and
> connect to my local LDAP server on my NT box at home. After the
> initial compilation it was quick, but until then...
> 
> Though I wonder if perhaps this is an issue that can be taken care
> of smarter caching or configuration. For example if I don't change
> my JSPs between startups, why should the servlet engine
> recompile it? Couldn't we just make a hash of the JSP and store it
> first and then check to see if it's changed between startups before
> we recompile. And if it hasn't can't we just reload the servlet we've
> recompiled (if we're already doing this, please accept my humble
> apoligies).
> >
> > If we discuss about how the request is processed - including authentication -
> > I'm interested to hear how much processing is part of the critical path,
> > how and what alghoritms and data structures can we use to implement
> > the parsing and searching, and how can we reuse existing code.
> >
> I agree. I think that we're concentrating so much on particular
> issues we're missing the bigger picture (e.g. missing the forest for
> the trees).
> 
> 
> 
> > If we discuss about authentication - I'm interested how can we address
> > existing systems ( like apache + any auth module). In a controled
> > environment everything works fine and looks flexible.
> >
> I think we handle communication with the Web server via the
> protocol.
> 
> Which also brings up the question, do we continue to use our
> current protocol or a different one. For example does it need to be
> TCP based or could it be UDP? Or do we investigate something
> like CORBA or even Mozilla's XPCOM (not Mozilla itself just the
> XPCOM protocol).
> 
> BTW Is it ok to post code samples here as zips or should I put
> them on the net somewhere for someone to pick up and place in
> CVS?
> 
> Mark
> > Costin
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
> >
> >
> >
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org

-- 
----------------------------------------------------------------------
Assaf Arkin                                           www.exoffice.com
CTO, Exoffice Technologies, Inc.                        www.exolab.org

Re: authorization providers (was More on JAAS)

[ma...@mjwilcox.com]

On 18 Apr 00, at 21:14, Costin Manolache wrote:

> Mark,
> 
> > I'm all for discussion. After all this is rather groundbreaking stuff.
> > While 'tis true that all of the popular Web servers use a filter model
> > similar to our interceptor model, they also all use C to write their
> > servers. (IIS may use C++, but if it follows MS tradition that is just
> > C++ wrappers around straight C code like the Windows API).
> 
> You can modules in Perl too. And soon - I hope - you'll be able to
> write modules in Java !
I know about Perl (that's the day job ;) and Apache. There's also a 
simplistic Perl api for Netscape and I think you can do something 
in IIS, but the point is that even with Perl, the underlying 
architecture is still primarily derived because the server itself is in C.
> 
> 
> > And while it is also true that most of our initial deployments will
> > ship with a standard Web server (most likely Apache) that may not
> > always be the case.
> 
> Sure - but whatever design  should still be able to
> address Apache integration and be useable in production sites -
> real web servers with real high load.
> 
> Do you think the Realm interface with the 2 methods is the
> right solution for authentication ?
At the moment yes. I think most of the time people are going to do 
something that takes a userid and password & then compare that 
to some database, whether that's LDAP, JAAS, password file, a 
database, etc.

I think we can handle extensions (e.g. X509, kerberos) by passing 
in a byte array that is the credentials.

This still requires a callback somewhere to populate the roles. (or 
does it? I thought perhaps SecurityCheck could call isUserInRole 
and if true add the role to the request, if not, remove or don't add 
the role)
> 
> What model for request processing do you prefer ?
> 
> My personal preference is to use Event and EventListeners -
> they have a simpler design and resolve the same problem.
> Maybe one day I'll just implement that as a revolution,
> with a lot more care for GC.
> But I'm not sure it is "better" - and I'll not be sure until
> I have a prototype and I can compare it and see how it works
> in real world.

Actually that's what I've been thinking as well. That perhaps we 
have an AuthenticateEvent and AuthorizationEvent. I'm still thinking 
on what would make this up (e.g. what gets passed to what).

Though I think you need the events to be a two-way street. 


> 
> Web servers have a long history and a lot of smart developers,
> and this model seems to work - and it was more than used in
> all those years. I need more than words to use something
> out of whiteboards.
I agree completely. That's why I think perhaps for 3.x we should 
just get something to work. We're already pretty close in terms 
that we can replace the SecurityInterceptor with something and 
authenticate & even authorize a user with a userid & password.

If we can figure the quickest way to get roles popluated, then I 
think we'll be rather set. I'd be happy to add in the callbacks if 
someone can at least tell me where I need to put in the hooks. 

Then for 4 we can get something better in place. This is sort of like 
Apache. 1.3.x was make it work. 2.0 is how to make it work now 
knowing what we know.

All of this stuff is just so new, I don't think we know enough really 
to say yea or ney on much of anything (in particular since we've 
only dealt with the theoretical so far ;). 

I'd also be happy to tackle the event issue, though that's going to 
be a while (most likely) since that's not an area I'm real familiar 
with and I'm committed to several projects in May (though after 
May, I'm pretty free).
> 

> > So while I agree Tomcat will/shouldn't replace the everyday
> > workhorse Web servers, there are areas where it likely will fill in
> > where we cannot see (if you can, make sure you have access to
> > some VC because you'll likely cash in big).
> 
> If we expect people to use servlets/jsp instead or in addition to
> mod_perl/php/asp we should be able to run in similar conditions
> with similar speed. If the response time is more than 2 seconds -
> nobody cares that your software can also run from a toaster. If you can't
> use the same authentication as the rest of your applications -
> nobody cares that you have plugeable  APIs or original architecture.
Yes, I just had to wait several seconds for my JSP to compile and 
connect to my local LDAP server on my NT box at home. After the 
initial compilation it was quick, but until then... 

Though I wonder if perhaps this is an issue that can be taken care 
of smarter caching or configuration. For example if I don't change 
my JSPs between startups, why should the servlet engine 
recompile it? Couldn't we just make a hash of the JSP and store it 
first and then check to see if it's changed between startups before 
we recompile. And if it hasn't can't we just reload the servlet we've 
recompiled (if we're already doing this, please accept my humble 
apoligies).
> 
> If we discuss about how the request is processed - including authentication -
> I'm interested to hear how much processing is part of the critical path,
> how and what alghoritms and data structures can we use to implement
> the parsing and searching, and how can we reuse existing code.
> 
I agree. I think that we're concentrating so much on particular 
issues we're missing the bigger picture (e.g. missing the forest for 
the trees).

 

> If we discuss about authentication - I'm interested how can we address
> existing systems ( like apache + any auth module). In a controled
> environment everything works fine and looks flexible.
> 
I think we handle communication with the Web server via the 
protocol.  

Which also brings up the question, do we continue to use our 
current protocol or a different one. For example does it need to be 
TCP based or could it be UDP? Or do we investigate something 
like CORBA or even Mozilla's XPCOM (not Mozilla itself just the 
XPCOM protocol).

BTW Is it ok to post code samples here as zips or should I put 
them on the net somewhere for someone to pick up and place in 
CVS?

Mark
> Costin
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
> 
> 
> 

Re: authorization providers (was More on JAAS)

[Costin Manolache <co...@costin.dnt.ro>]

Mark,

> I'm all for discussion. After all this is rather groundbreaking stuff.
> While 'tis true that all of the popular Web servers use a filter model
> similar to our interceptor model, they also all use C to write their
> servers. (IIS may use C++, but if it follows MS tradition that is just
> C++ wrappers around straight C code like the Windows API).

You can modules in Perl too. And soon - I hope - you'll be able to
write modules in Java !


> And while it is also true that most of our initial deployments will
> ship with a standard Web server (most likely Apache) that may not
> always be the case.

Sure - but whatever design  should still be able to
address Apache integration and be useable in production sites -
real web servers with real high load.

Do you think the Realm interface with the 2 methods is the
right solution for authentication ?

What model for request processing do you prefer ?

My personal preference is to use Event and EventListeners -
they have a simpler design and resolve the same problem.
Maybe one day I'll just implement that as a revolution,
with a lot more care for GC.
But I'm not sure it is "better" - and I'll not be sure until
I have a prototype and I can compare it and see how it works
in real world.

Web servers have a long history and a lot of smart developers,
and this model seems to work - and it was more than used in
all those years. I need more than words to use something
out of whiteboards.

> So while I agree Tomcat will/shouldn't replace the everyday
> workhorse Web servers, there are areas where it likely will fill in
> where we cannot see (if you can, make sure you have access to
> some VC because you'll likely cash in big).

If we expect people to use servlets/jsp instead or in addition to
mod_perl/php/asp we should be able to run in similar conditions
with similar speed. If the response time is more than 2 seconds -
nobody cares that your software can also run from a toaster. If you can't
use the same authentication as the rest of your applications -
nobody cares that you have plugeable  APIs or original architecture.

If we discuss about how the request is processed - including authentication -
I'm interested to hear how much processing is part of the critical path,
how and what alghoritms and data structures can we use to implement
the parsing and searching, and how can we reuse existing code.

If we discuss about authentication - I'm interested how can we address
existing systems ( like apache + any auth module). In a controled
environment everything works fine and looks flexible.

Costin

Re: authorization providers (was More on JAAS)

[Costin Manolache <co...@costin.dnt.ro>]

>
> * They can both be used to implement "filter" (the request passes
>   on through) or "handler" (the request is handled, and no further
>   processing happens).  This latter capability of RequestInterceptors
>   was not obvious in the code (lack of comments) to me earlier --
>   I apologize for mis-stating this in an earlier email.

With a big difference...


> * State Management -- Both RequestInterceptors and Valves are
>   used in a multithreaded environment (thread per concurrent
>   request).  As a result, any state about this request that a
>   RequestInterceptor wants to save must be stored in the request
>   itself.  In a Valve, you can do that (important if some other
>   component needs access to this information) but you can also
>   use local variables inside the invoke() method for state information
>   that is purely local to this request.

Are we going back to "recursive versus iterative alghoritms"  ?
Yes, you get the ability to store local variables on the invocation stack -
but  that's not allways an advantage.

> * Complexity -- RequestInterceptor provides you circa 10 entry points,
>   and you must understand the request processing lifecycle in pretty
>   good detail to know where your logic should go.  Valves are called
>   once per request, so this is quite obvious.  See more on this topic
>   below; there are other subtleties.

Well, you must understand the request processing in both cases...


> * Performance Overhead -- A RequestInterceptor that passes requests
>   on (the usual case) receives circa 10 method calls per request, versus
>   one for a Valve.  In addition, the requirement to store state information
>   in the request, as opposed to on the stack, can cause additional
>   overhead to implement the same functionality.

First "overhead" - it's an implementation problem, nothing wrong with the
interface.
The second - I just a result of the alghortim choice, and interceptors are
supposed to be very simple, we tried very hard to keep even the
configuration as part of the "core objects" - i.e. you configure the
context, not the interceptor. If the state is associated with the request -
it's better to keep it in the request, instead of doing tricks with
the execution stack.

But if you want to discuss "performance overhead" - the request interceptor
have full control over the parsing alghoritm. It can use a BTree or any
other data structure - and that _does_ matter in execution time.
With Valve  -  you impose a certain method ( division of problem space)
and prevent any optimizations that can result from using efficient data
structures.

The reason Valve looks nice on paper is that it doesn't have to deal with
all the details of the request processing - subRequests, etc. Looking forward
to see how Catalina will perform and see where is the overhead.


> The key question, though, is "can I implement something using one approach
> that I cannot implement in the other".  The only place I can see a big
> difference here is the case where you want all of the interceptors to have a
> crack at, say, the requestMap() call, then go back and call all of them again
> for the authenticate() call.  (For those of you familiar with Apache modules,
> that's the way they work).  While one could discuss how often you need that
> kind of thing inside a servlet container (versus when writing webserver
> extensions), it can be implemented when needed with Valves by simply having
> more than one Valve in the pipeline, using shared state behind the scenes as
> required to accomplish the functional purpose required.

Sounds simple :-)

The situation is very common - for example include() and all getRealPath().
But we are going back to alghoritms - it's a problem common to recursive
programming, it's hard to control entry and exit.

Another thing you can't do with valves - you can't distinguish between
various proessing stages. The reason interceptor has 10 methods is that
there _are_  several distinct stages, and you have better control by
exposing them instead of hiding them in the processing chain ( inside
invoke() method).

You may want to check if a particular resource is "authorized" - the user
is authenticated and calls getResource() ( I know it's not required by the
spec, but spec do change) , you have the context  and you just need to call
the authorization stage.
Or getContext(uri) - you don't need to call the full valve chain, only the
valves that are involved in context mapping.


Costin

Re: authorization providers (was More on JAAS)

[Costin Manolache <co...@costin.dnt.ro>]

> The issue I was addressing is, where do I keep state information specific to
> this particular interceptor related to this particular request?  Because
> there's only one instance of the interceptor (so you cannot use instance
> variables unless you internally key things by thread), and you cannot use
> local variables (they go away as each handler method returns) to keep state
> information from one handler method to the next handler method in that same
> interceptor.
>
> It's not that you cannot store state information for this purpose -- it's
> just a little more complicated to have to use something like request
> attributes for things that are (from a logical perspective) private to this
> interceptor.

The local variables are visible only inside invoke(). That means even inside
the same Valve - you can't share them, but just use inside the invoke() method.

Having local variables inside a method ( that are used before and after
the method pass control to the next one in chain) is not so much "less
complicated", and I don't think  it should be on the list of "requirements" for
a
servlet container or subject to "feature comparation" between 2
patterns ...


Costin

Re: authorization providers (was More on JAAS)

["Craig R. McClanahan" <Cr...@eng.sun.com>]

Costin Manolache wrote:

> > * State Management -- Both RequestInterceptors and Valves are
> >   used in a multithreaded environment (thread per concurrent
> >   request).  As a result, any state about this request that a
> >   RequestInterceptor wants to save must be stored in the request
> >   itself.  In a Valve, you can do that (important if some other
> >   component needs access to this information) but you can also
> >   use local variables inside the invoke() method for state information
> >   that is purely local to this request.
>
> BTW, how is that working ??? Assuming you have a valve A and
> a valve B, A calling B.invoke() - how can B access the local variables
> in A ?
>

It cannot, unless you store them someplace more public (like request
attributes).  On the other hand, my view is that most interceptors will be
pretty much independent of other interceptors, so this will be the exception
rather than the rule.

The issue I was addressing is, where do I keep state information specific to
this particular interceptor related to this particular request?  Because
there's only one instance of the interceptor (so you cannot use instance
variables unless you internally key things by thread), and you cannot use
local variables (they go away as each handler method returns) to keep state
information from one handler method to the next handler method in that same
interceptor.

It's not that you cannot store state information for this purpose -- it's
just a little more complicated to have to use something like request
attributes for things that are (from a logical perspective) private to this
interceptor.

>
> Costin
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org

Re: authorization providers (was More on JAAS)

[Costin Manolache <co...@costin.dnt.ro>]

> * State Management -- Both RequestInterceptors and Valves are
>   used in a multithreaded environment (thread per concurrent
>   request).  As a result, any state about this request that a
>   RequestInterceptor wants to save must be stored in the request
>   itself.  In a Valve, you can do that (important if some other
>   component needs access to this information) but you can also
>   use local variables inside the invoke() method for state information
>   that is purely local to this request.

BTW, how is that working ??? Assuming you have a valve A and
a valve B, A calling B.invoke() - how can B access the local variables
in A ?



Costin

Re: authorization providers (was More on JAAS)

["Craig R. McClanahan" <Cr...@eng.sun.com>]

Shachor Gal wrote:

> <snip>
> >
> > I'm all for discussion. After all this is rather groundbreaking stuff.
> > While 'tis true that all of the popular Web servers use a filter model
> > similar to our interceptor model, they also all use C to write their
> > servers. (IIS may use C++, but if it follows MS tradition that is just
> > C++ wrappers around straight C code like the Windows API).
> >
>
> I am not saying "... Web server X does that, so we must blindly do it
> to ...", my point is that most web servers selected the interceptor model
> and it was not the programming language that forced them to select it (You
> can wrap objects within other object in almost any language). We should
> not just forget this.
>
> Note, I am not saying that we should go with "strict" interceptor model,
> only that I need to have a good reason to abandon it in favor of wrappers.
>

Gal, I'm assuming that by "wrappers" you are referring to the Valve approach
in Catalina versus the RequestInterceptor approach in Tomcat 3.x -- is that
right?  If not, could you please help me understand what you're referring to
there.

On the assumption that this is what you mean, a quick comparison of Valves
versus RequestInterceptors is interesting.  The key similarities:

* They can both be configured and deployed at startup time.

* They both have access to other components -- principally the
  internal request and response instances, but also other things
  like the Context.

* They can both be used to implement "filter" (the request passes
  on through) or "handler" (the request is handled, and no further
  processing happens).  This latter capability of RequestInterceptors
  was not obvious in the code (lack of comments) to me earlier --
  I apologize for mis-stating this in an earlier email.

There are also some differences:

* State Management -- Both RequestInterceptors and Valves are
  used in a multithreaded environment (thread per concurrent
  request).  As a result, any state about this request that a
  RequestInterceptor wants to save must be stored in the request
  itself.  In a Valve, you can do that (important if some other
  component needs access to this information) but you can also
  use local variables inside the invoke() method for state information
  that is purely local to this request.

* Complexity -- RequestInterceptor provides you circa 10 entry points,
  and you must understand the request processing lifecycle in pretty
  good detail to know where your logic should go.  Valves are called
  once per request, so this is quite obvious.  See more on this topic
  below; there are other subtleties.

* Performance Overhead -- A RequestInterceptor that passes requests
  on (the usual case) receives circa 10 method calls per request, versus
  one for a Valve.  In addition, the requirement to store state information
  in the request, as opposed to on the stack, can cause additional
  overhead to implement the same functionality.

The key question, though, is "can I implement something using one approach
that I cannot implement in the other".  The only place I can see a big
difference here is the case where you want all of the interceptors to have a
crack at, say, the requestMap() call, then go back and call all of them again
for the authenticate() call.  (For those of you familiar with Apache modules,
that's the way they work).  While one could discuss how often you need that
kind of thing inside a servlet container (versus when writing webserver
extensions), it can be implemented when needed with Valves by simply having
more than one Valve in the pipeline, using shared state behind the scenes as
required to accomplish the functional purpose required.

Given equivalence in "functional power" (or whatever you want to call it), I
tend to go for simplicity (especially when it reduces overhead, as is true in
this case).

NOTE:  There are lots of other things to consider when looking at
Catalina-vs-Tomcat-3.x -- and those things will change in the future -- but
request interception is one of the places where the two approaches differ the
most, and it's worth comparing them in depth.

Craig McClanahan

Re: authorization providers (was More on JAAS)

[Shachor Gal <sh...@techunix.technion.ac.il>]

<snip>
>
> I'm all for discussion. After all this is rather groundbreaking stuff.
> While 'tis true that all of the popular Web servers use a filter model
> similar to our interceptor model, they also all use C to write their
> servers. (IIS may use C++, but if it follows MS tradition that is just
> C++ wrappers around straight C code like the Windows API).
>

I am not saying "... Web server X does that, so we must blindly do it 
to ...", my point is that most web servers selected the interceptor model 
and it was not the programming language that forced them to select it (You 
can wrap objects within other object in almost any language). We should 
not just forget this.

Note, I am not saying that we should go with "strict" interceptor model,
only that I need to have a good reason to abandon it in favor of wrappers.

Also, I do not have anything against defining an object that the
authenticate step set inside the Request for the authorize step. I also 
would like us to define the notion of plugable security providers... I do
not
think however that this has anything to do with interceptors VS wrappers.

>
> We are talking about Java here and we should be looking for a
> proper Java solution. Perhaps this still leaves us with an interceptor
> based solution. But maybe it doesn't. I mean we haven't even
> talked about using things like reflection and dynamic loading.
> We're doing it for servlets, why not Tomcat itself?
>
Right on.
As for building Tomcat on the fly, we are not that far away...

</snip>

    Gal Shachor

Re: authorization providers (was More on JAAS)

[ma...@mjwilcox.com]

On 18 Apr 00, at 12:42, Craig R. McClanahan wrote:

> Shachor Gal wrote:
> 
> > I think that this argument get a little out of proportion here...
> >
> > You are comparing two completely different things:
> > 1. A working servlet container (Tomcat)
> > 2. A design that (relative to the above) is mostly on the blackboard.
> >
> > And, you make the comparison based on a portion of Tomcat that is known
> > to be unfinished...
> >
> 
> Hmm, unfinished versus incomplete ... sounds more similar than different :-)
I agree. After hacking on the interceptor all weekend, I'd say that 
we're definitely not something I would calll complete. ;)
> 
> Seriously, you're absolutely right -- we need a functional implementation of
> Catalina in order to compare on anything other than theoretical grounds.  One
> of my motivations in bringing this up is to start comparing design approaches,
> and hopefully garner some interest in helping to create just such a functional
> implementation.
> 
> 
I'm all for discussion. After all this is rather groundbreaking stuff. 
While 'tis true that all of the popular Web servers use a filter model 
similar to our interceptor model, they also all use C to write their 
servers. (IIS may use C++, but if it follows MS tradition that is just 
C++ wrappers around straight C code like the Windows API). 

We are talking about Java here and we should be looking for a 
proper Java solution. Perhaps this still leaves us with an interceptor 
based solution. But maybe it doesn't. I mean we haven't even 
talked about using things like reflection and dynamic loading. 
We're doing it for servlets, why not Tomcat itself?

And while it is also true that most of our initial deployments will 
ship with a standard Web server (most likely Apache) that may not 
always be the case.

Now that Mozilla is finishing up and we have something like 
Tomcat, this gives us a whole new set of tools to build new 
sophisticated Web applications that don't necessarily fit into our 
old patterns. For example perhaps you want to build a distributed 
database application for your sales force. You like the cool stuff 
Java brings in the form of JDBC, RMI, etc for doing distributed 
database development, but SWING programming sucks, in 
particular when compared to HTML. You could instead build the 
interface using XUL/Javascript and some CSS. Because Mozilla 
can switch skins easily you can build a suite of applications that 
look/act differently but use the same underlying technology.

Thus Mozilla becomes the front-end. You use a local server-side 
component to run the actual application. You don't really need 
Apache, when you simply need a servlet engine. Might as well use 
Tomcat. 

So while I agree Tomcat will/shouldn't replace the everyday 
workhorse Web servers, there are areas where it likely will fill in 
where we cannot see (if you can, make sure you have access to 
some VC because you'll likely cash in big). 

Mark
> >
> >     Gal Shachor
> 
> Craig McClanahan
> 
> 
> 
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
> 
> 
> 

Re: authorization providers (was More on JAAS)

["Craig R. McClanahan" <Cr...@eng.sun.com>]

Shachor Gal wrote:

> I think that this argument get a little out of proportion here...
>
> You are comparing two completely different things:
> 1. A working servlet container (Tomcat)
> 2. A design that (relative to the above) is mostly on the blackboard.
>
> And, you make the comparison based on a portion of Tomcat that is known
> to be unfinished...
>

Hmm, unfinished versus incomplete ... sounds more similar than different :-)

Seriously, you're absolutely right -- we need a functional implementation of
Catalina in order to compare on anything other than theoretical grounds.  One
of my motivations in bringing this up is to start comparing design approaches,
and hopefully garner some interest in helping to create just such a functional
implementation.


>
>     Gal Shachor

Craig McClanahan

Re: authorization providers (was More on JAAS)

[Shachor Gal <sh...@techunix.technion.ac.il>]

I think that this argument get a little out of proportion here...

You are comparing two completely different things:
1. A working servlet container (Tomcat)
2. A design that (relative to the above) is mostly on the blackboard.

And, you make the comparison based on a portion of Tomcat that is known
to be unfinished...

The way I see it, the Realm object as well as the Host, Logger and other
Catalina objects are not the big deal here. We can have the same objects
alive and kicking in Tomcat in a shorter time (nothing in Tomcat block us
from having a Realm class for example ...) This is mainly an
implementation
step. Think for a moment, had Craig developed the Tomcat security
subsystem he could add this Realm object without a problem... No one would
-1 it because it is a (relatively) minor change.

The main issue, and this is what we do not really talk about, is the nuts
and bolts of the difference:
- Tomcat is based on request manipulation through interceptors that
  eventually selects the wanted context and execute it.
  It is very simple.
  It is very flexible.
  It looks messy.

- In Catalina the request will traverse through Containers until they will
  arrive to the correct container and in this container to the correct
  context.
  It is relatively complex,
  It is very flexible.
  It looks clean (can not rally judge without a real implementation).

This is the real difference, not the Realm/plugable XXX/Extensible YYY...
By
adding to the current Tomcat code we can accomplish all the goals listed
by Craig (in the Catalina document) and it will be faster!!!

>
> >
> > What is missing in the current model? It seems all web servers ( IIS,
Nes,
> Apache
> > at least) are doing fine with the filter/SAF/module model.
> >
>
> One particular thing that's missing is a way to implement isUserInRole()
> without
> adding another callback.
>
> On a larger scale, and as we will discuss more, I'm sure, Tomcat is not
a web
> server
> -- that problem has been solved quite nicely, thank you.  Instead, it is
a
> container
> for web based applications, which do not necessarily have the same
requirements
> for
> functionality (or even the same sweet spots for performance
optimizations).
> Doing things in Tomcat "just because web servers do them that way" is
not a
> sufficient argument, without understanding the costs imposed by that
design.
......

iPlanet and IIS are (for mow at least) more of a web application server
then
tomcat, and they manage to get the work done using (mainly) filters and
iteration. But this is not the issue, the issue is:
Do we need in Tomcat/Catalina .... an architecture that is based on
wrappers ? Is there a single goal that we can not achieve with an improved
filter (interceptors) based architecture that we have today?

    Gal Shachor

Re: authorization providers (was More on JAAS)

["Craig R. McClanahan" <Cr...@eng.sun.com>]

Costin Manolache wrote:

> > This is one of the reasons that I defined a separate Realm object in the
> > Catalina architecture (see directory "proposals/catalina" in the source CVS
> > repository).  A Realm is a very thin API that provides only what the servlet
> > container needs to satisfy its requirements -- implementations on top of JNDI,
> > JAAS, or whatever are quite easy to create.
>
> That's exactly what I said - but in reverse :-)
>
> - How do you plan to integrate between web-server-based authentication
> and tomcat ? ( static files are served by the web server ).

Two different approaches are feasible:
* A Realm implementation that directly reads the same files, or
* A Realm implementation that knows it's running with a web server
  connector and uses the proprietary webserver-Tomcat protocol to
  ask the questions it needs.

In other words, its exactly the same amount of new code you would add in a subclass
of SecurityCheck to do the same thing.

>
> - How can you implement "trust only users from a certain IP domain ( a very valid
> and common security restriction )"?
>

Even easier (and doesn't require a Realm) - a Valve that looks at the value returned
by getRemoteAddr() or getRemoteHost() and applies the filters you've configured.  One
thing Valves can do that RequestInterceptors cannot is to handle the request and
return (in this case, the IP filter Valve would return
HttpServletResponse.SC_FORBIDDEN), instead of passing the request on to the rest of
the engine - in particular, no Valve or Container after this filter would even see
requests from invalid IP domains.  You'd undoubtedly deploy this Valve earlier in the
request processing pipeline than the security check, to avoid wasting the time to
look up a user you're not going to accept anyway because of the IP address filtering.

>
> And most important question:
>
> Why use an interface that doesn't provide you anything that is not already
> available, but reduce the flexibility and add complexity ?
>

As Stefano would say :-), the issue is "separation of concerns".  The fundamental
design issue that Catalina changes vs. Tomcat 3.x (in respect to security) is a
separation between the following concepts:

* the mechanics of enforching the authentication rules defined in web.xml
  (for example, doing the challenge for BASIC authentication).

* the "database-like" lookup of users and roles, by default done against
  the "MemoryRealm" private class in SecurityCheck.

In the current architecture, you have to subclass SecurityCheck to create a link to
something different than the conf/tomcat-users.xml file -- as Mark did.  Now,
consider some issues:

* How do you implement request.isUserInRole()?  (This was Mark's
  comment that sparked the current discussion).  Currently, there's
  no way for the request implementation to "get to" the underlying
  realm you've loaded into the interceptor.  The proposed solution
  is to add yet another method callback to the 9 or 10 already there
  in RequestInterceptor.  Like most of the other ones, this is only
  needed to get around the fact that the two concepts above are
  combined instead of separated.

* What happens when another authentication method is added in
  some future version of the servlet API?  The current architecture
  forces you to add it to SecurityCheck (plus side effects on at least
  three other source modules, instead of being able to do everything
  in one place).  With Catalina, you can do that all in a single class,
  or define a separate Valve for each type of authentication that is
  installed when you read web.xml to see what is necessary.  And,
  you can mix and match any authentication method with any Realm
  implementation -- they don't have a common subclass, so they
  can be developed and deployed independently.

Finally, it's amusing to note that this doesn't really add a new kind of object :-).
We already have a MemoryRealm object with similar characteristics -- it's just hidden
inside SecurityCheck (as a private class) instead of being public where it is more
useful.



>
> What is missing in the current model? It seems all web servers ( IIS, Nes, Apache
> at least) are doing fine with the filter/SAF/module model.
>

One particular thing that's missing is a way to implement isUserInRole() without
adding another callback.

On a larger scale, and as we will discuss more, I'm sure, Tomcat is not a web server
-- that problem has been solved quite nicely, thank you.  Instead, it is a container
for web based applications, which do not necessarily have the same requirements for
functionality (or even the same sweet spots for performance optimizations).

Doing things in Tomcat "just because web servers do them that way" is not a
sufficient argument, without understanding the costs imposed by that design.  (For
example, have you counted the number of empty method calls the current Interceptor
design causes to happen on every request?  They are fairly cheap, but they are
definitely not free.)

>
> The interceptor is not supposed to implement password-based authentication -
> it is just a _bridge_ between tomcat and the real backend - that can be anything,
> including Realm ( or JAAS, or JNDI ). With the addition that you can take
> complex decisions based on the full request.
> Reading from JAAS - it may be a smart card or an eye-scanning device -
> hard to fit it into authenticate( String user, char credentials[])  :-)
>

No difference if the Realm is publicly visible or not.  If Realms need the full
request content to authenticate (probably necessary for SSL-based authentication at
least), adding another authenticate() message signature to pass it will be the right
answer.

>
> > But of course - a different class needs to be used to authenticate using
>
> > > SSL certificates for example.
> > > And another type to just integrate with  the Apache auth ( if you
> > > let apache do the authentication and authorization - you don't want
> > > your static files authenticated from a different database, and it's
> > > clear that static files served by apache is important to support)
> > >
> >
> > The logic of performing BASIC or DIGEST of FORM based authentication is plenty
> > complicated enough, without trying to mold in authentication lookups.  It is
> > also *independent* of the way that you do the password authentication and role
> > identification.  That really needs to be its own component.
>
> Yes - the interceptor is not supposed to implement authentication lookups, but to
> _use_ a component. With the difference that the authentication component is not
> imposed by tomcat, but it's anything you want, with any interface. It needs to be
> in its own component - but the component is not under our control, we should use
> existing systems where possible.
>

The *interface* to the component is being defined (that's what Realm is for) so you
can plug in the implementation you want.  This interface defines only what Tomcat
needs to satisfy its questions ("is this user authenticated?"  "is this user in this
role?").  Realm does not impose any restrictions on *how* those questions are
answered.

As mentioned above, you've already done exactly the same thing inside SecurityCheck
-- it's just hidden, so it's not useful quite everywhere it needs to be.  I'm
proposing that people be able to implement realms independent of messing with
SecurityCheck.

>
> Costin
>

Craig

Re: authorization providers (was More on JAAS)

[Costin Manolache <co...@costin.dnt.ro>]

> This is one of the reasons that I defined a separate Realm object in the
> Catalina architecture (see directory "proposals/catalina" in the source CVS
> repository).  A Realm is a very thin API that provides only what the servlet
> container needs to satisfy its requirements -- implementations on top of JNDI,
> JAAS, or whatever are quite easy to create.

That's exactly what I said - but in reverse :-)

- How do you plan to integrate between web-server-based authentication
and tomcat ? ( static files are served by the web server ).
- How can you implement "trust only users from a certain IP domain ( a very valid
and common security restriction )"?

And most important question:

Why use an interface that doesn't provide you anything that is not already
available, but reduce the flexibility and add complexity ?

What is missing in the current model? It seems all web servers ( IIS, Nes, Apache
at least) are doing fine with the filter/SAF/module model.

The interceptor is not supposed to implement password-based authentication -
it is just a _bridge_ between tomcat and the real backend - that can be anything,
including Realm ( or JAAS, or JNDI ). With the addition that you can take
complex decisions based on the full request.
Reading from JAAS - it may be a smart card or an eye-scanning device -
hard to fit it into authenticate( String user, char credentials[])  :-)


> But of course - a different class needs to be used to authenticate using

> > SSL certificates for example.
> > And another type to just integrate with  the Apache auth ( if you
> > let apache do the authentication and authorization - you don't want
> > your static files authenticated from a different database, and it's
> > clear that static files served by apache is important to support)
> >
>
> The logic of performing BASIC or DIGEST of FORM based authentication is plenty
> complicated enough, without trying to mold in authentication lookups.  It is
> also *independent* of the way that you do the password authentication and role
> identification.  That really needs to be its own component.

Yes - the interceptor is not supposed to implement authentication lookups, but to
_use_ a component. With the difference that the authentication component is not
imposed by tomcat, but it's anything you want, with any interface. It needs to be
in its own component - but the component is not under our control, we should use
existing systems where possible.


Costin

Re: authorization providers (was More on JAAS)

["Craig R. McClanahan" <Cr...@eng.sun.com>]

Costin Manolache wrote:

[snip]

> > 3) we should be able to populate the Roles object
> > While I can authorize a user per role (e.g. LDAP group), I cannot
> > set the Roles value for when someone wants that information from
> > request.getRoles().
>
> Regarding the Roles - the last resort is to add a new callback in the
> requestInterceptor - that will allow various security interceptors to
> work without introducing a new interface.
>

This is one of the reasons that I defined a separate Realm object in the
Catalina architecture (see directory "proposals/catalina" in the source CVS
repository).  A Realm is a very thin API that provides only what the servlet
container needs to satisfy its requirements -- implementations on top of JNDI,
JAAS, or whatever are quite easy to create.

An assigned Realm is a property of the Context (conceptually, it's part of the
environment of a web app, not related to a particular request), independent of
the "business logic" found in the security check interceptor.  Now, the
implementation of HttpServletRequest.isUserInRole() need only call

    context.getRealm().isUserInRole(role);

to get the answer, no matter which Realm component is actually in use.

Also, when Catalina is extended to support "single sign on" to multiple apps,
the necessary lookup support will already be there, because you can attach the
Realm to the virtual host container instead of the context container.

>
> > What was great about this was that the SEcurityCheck class could
> > take care of parsing username and password, making sure that
> > any other requirements were met, etc.
>
> But of course - a different class needs to be used to authenticate using
> SSL certificates for example.
> And another type to just integrate with  the Apache auth ( if you
> let apache do the authentication and authorization - you don't want
> your static files authenticated from a different database, and it's
> clear that static files served by apache is important to support)
>

The logic of performing BASIC or DIGEST of FORM based authentication is plenty
complicated enough, without trying to mold in authentication lookups.  It is
also *independent* of the way that you do the password authentication and role
identification.  That really needs to be its own component.

[snip]

> > I'm under a tight deadline right now to finish my chapter that started
> > all of this. I'll try to get at least my source code published to the
> > Web this week (if people want me to submit it to Tomcat, I can, but
> > I'd rather wait until this is settled).
>
> Whenever you want - if it's an independent interceptor I see no possible
> reason to not check it in - maybe not as part of the core, but at least in
>
> a proposal state, so other people can contribute and add to it.
>

+1 for posting it in Tomcat (at least as a proposal) when you're ready.

>
> Costin
>

Craig

Re: authorization providers (was More on JAAS)

[Costin Manolache <co...@costin.dnt.ro>]

> 1) First people should be able freely write security interceptors as
> they see fit.
>
> I think that we can make this fairly general enough that people will
> be able to add in whatever authentication mechanism they
> need/want. Just look at the Apache authentication modules. Even if
> someone writes a version for a particular protocol (e.g. LDAP) it
> may not fit what a person needs. For example when I went a
> looking for an LDAP module for Apache, I found 2, both based
> around the C API. Which wasn't too bad except that neither one
> supported LDAP groups, something I needed. So I wrote my own,
> primarily to support LDAP groups but also in Net::LDAP which is
> pure Perl, thus I no longer needed a C compiler for the module.

That's my opinion too.
It also  true for IIS and NES.

> 2) Make the security interceptor into a driver/manager format.
>
> We should be able to load more than 1 interceptor at a time and
> they should be able to chain themselves together.

We can do that right now - you can chain multiple interceptors.
We need to test and extend that ( one big piece that has to be
implemented is per/context or container interceptors - we have
the stubs but it never got implemented ).


> 3) we should be able to populate the Roles object
> While I can authorize a user per role (e.g. LDAP group), I cannot
> set the Roles value for when someone wants that information from
> request.getRoles().

Regarding the Roles - the last resort is to add a new callback in the
requestInterceptor - that will allow various security interceptors to
work without introducing a new interface.

> What was great about this was that the SEcurityCheck class could
> take care of parsing username and password, making sure that
> any other requirements were met, etc.

But of course - a different class needs to be used to authenticate using
SSL certificates for example.
And another type to just integrate with  the Apache auth ( if you
let apache do the authentication and authorization - you don't want
your static files authenticated from a different database, and it's
clear that static files served by apache is important to support)

> The only item I really lacked was the ability to populate the roles
> as I said before. This could be fixed in the Security Interceptor by
> populating a hashtable or map that was updated on each call to
> userInRole and then passed onto the Request object.

Either that ( if the roles are known by the security interceptor -
I think that's true in most cases), or add a new callback that will
allow interceptors to do that in a "lazy" mode.

> I'm not exactly sure how to handle multiple interceptors yet.

If we finish the per/context interceptor - we solve 1/2 of the
problem.

Also look at SimpleMapper versus Adapter - if the adapter
knows the Context/ServletPath/PathInfo the mapper will just
skip the processing.
Same model is used in apache - the first interceptor that is
able to authenticate will return a SKIP result and ContextManager
will stop the loop.

> The actual implementors of the interceptors could use whatever
> mechanism they wished (JNDI, JAAS, Kerberos, etc) as long as
> they extended the proper class.

Base class is a helper - I think it's better to not impose any
restriction ( like extend a class ) - the apache auth modules
are valid mechanisms to use !

> I'm under a tight deadline right now to finish my chapter that started
> all of this. I'll try to get at least my source code published to the
> Web this week (if people want me to submit it to Tomcat, I can, but
> I'd rather wait until this is settled).

Whenever you want - if it's an independent interceptor I see no possible
reason to not check it in - maybe not as part of the core, but at least in

a proposal state, so other people can contribute and add to it.

Costin