Security in tomcat

[co...@eng.sun.com]

Hi,

There are 3 issues with implementing security:

1. User authentication - a simple interceptor can handle that, it will
check for "user" and "password" and use it's own database to check if it
match. For example an LDAP auth interceptor will look into LDAP, etc.

One subproblem might be extracting user and password ( we can have Basic,
Digest, SSL or form auth ), but that's more of a "util" helper, I don't
think we should try to abstract it until we have some implementations to
get a feeling of what we need. 

Probably the module will also set the "roles" for the particular user.
( probably a users will have few roles, and the data will be available at
the time of authentication - if we make isUserInRole( role ) a callback 
we'll need to make another query to the authentication system, which is
probably expensive for anything but trivial in-memory systems).


2. Authorization. We have to duplicate the Mapper code ( which parse a
request URI to find the servlet that will handle the request). We have
security constraints associated with URLs, and we need to check every
access if it's a "restricted" area and authorize. 

IMO a very good solution would be to combine the security and mapper code
in SimpleMapper ( or whatever mapper we'll implement). The mapper will
have a set of patterns ( both mappings and security restrictions ), and 
will find the matches for a URI. The advantage is that we have one common
code that can be optimized.

3. Form login. That's probably easy, it should be just a redirect ( and
probably we can just reuse the "error page" code ( un-authorized access
is an error anyway)!

Costin

Re: Security in tomcat

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

JAAS is sort of a work in progress. Some of the ideas there are very
good, and I plan to use them, some stuff is just not well specified, so
we'll need to figure that out as we go along.

JAAS is not dependent on 1.3. Caller-based permissions are available in
1.3 only, but for Tomcat you only need role-based permissions, so it can
be done with 1.2.

arkin

Geoff Soutter wrote:
> 
> > There are 3 issues with implementing security:
> >
> > 1. User authentication - a simple interceptor can handle that, it will
> > check for "user" and "password" and use it's own database to check if it
> > match. For example an LDAP auth interceptor will look into LDAP, etc.
> 
> I'm no expert on this, but JAAS would be cool to use with this, but it's
> JDK1.3 only :-(
> it supposedly lets you plug in to any back end for authentication
> I think it comes with a JNDI back end that would do LDAP for you?
> 
> l I suppose you could have a (single) JAASAuthInterceptor for those that are
> running 1.3, and (multiple) others for those that are not.
> 
> geoff
> 
> ---------------------------------------------------------------------
> 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: Security in tomcat

[Geoff Soutter <ge...@whitewolf.com.au>]

> There are 3 issues with implementing security:
>
> 1. User authentication - a simple interceptor can handle that, it will
> check for "user" and "password" and use it's own database to check if it
> match. For example an LDAP auth interceptor will look into LDAP, etc.

I'm no expert on this, but JAAS would be cool to use with this, but it's
JDK1.3 only :-(
it supposedly lets you plug in to any back end for authentication
I think it comes with a JNDI back end that would do LDAP for you?

l I suppose you could have a (single) JAASAuthInterceptor for those that are
running 1.3, and (multiple) others for those that are not.

geoff

Re: Security in tomcat

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

"Craig R. McClanahan" wrote:
> 
> jon * wrote:
> 
> > on 2/10/00 11:42 AM, costin@eng.sun.com <co...@eng.sun.com> wrote:
> >
> > > Hi,
> > >
> > > There are 3 issues with implementing security:
> >
> > I feel pretty strongly that this should not be implemented in the servlet
> > engine. It should be implemented in the framework that you use.
> >
> > That is why I came up with Turbine in the first place. It gives you the
> > ability to implement security any way that you want very easily.
> >
> 
> However, in order to conform to the servlet spec 2.2 requirements, this
> stuff *must* be implemented within the servlet container.  Thus, the issue
> of how to do so remains.
> 
> Also, if you have a 2.2 container that supports this, you no longer have to
> worry about it at the application level at all ...

Actually implemented as a separate back-end that plugs into the Servlet
container and exposed through the Servlet API.

This way you get authentication and security not just for your
application, but for all the resources you application is using (EJB,
JDBC, LDAP, etc).

That's not something an application can give you without writing lots of
code.

arkin


> 
> >
> > -jon
> >
> 
> 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: Security in tomcat

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

> Should we define a security API ( sort of common API for all
> authentication services ) ? Probably, but not as part of tomcat, it's
> much to big.

JAAS attempts to do that, and will eventually get there (the API is not
mature enough).

Servlets can use some security provider that can pre-authenticate you at
the point of PPP, IPSEC, Firewall, whatever and carry that
authentication into the Servlet. It then has to pull out the proper
credentials for you (i.e. roles).

So, essentially all the Servlet container needs is a way to plug into a
security provider, a very simple API.

arkin


> 
> > Also, if you have a 2.2 container that supports this, you no longer have to
> > worry about it at the application level at all ...
> 
> You should worry about security at all levels! :-)
> 
> 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: Security in tomcat

[co...@eng.sun.com]

> 
> However, in order to conform to the servlet spec 2.2 requirements, this
> stuff *must* be implemented within the servlet container.  Thus, the issue
> of how to do so remains.

I think Jon was talking about user/password authentication, and we can't
force an application to use our authentication mechanism. 

I think in general we should expect an existing realm ( LDAP, NT registry,
PAM, Radius, Tacacs ). An ISP will probably use Tacacs or Radius to
authenticate users on ppp lines, and he'll want to use the same password
for tomcat serlvets ( Apache can do that - it used to be a mod_radius,
that allowed apache to authenticate ). If you have NIS passwords, you
don't want to type all users and passwords into tomcat config.

For authorization, of course, we need to do it, and we also need to
provide a simple realm, your FileRealm and interfaces are perfect for
that ( I'll integrate them in the main tree if you don't mind ) . 

Should we define a security API ( sort of common API for all
authentication services ) ? Probably, but not as part of tomcat, it's
much to big. 


> Also, if you have a 2.2 container that supports this, you no longer have to
> worry about it at the application level at all ...

You should worry about security at all levels! :-)

Costin

Re: Security in tomcat

["Craig R. McClanahan" <cm...@mytownnet.com>]

jon * wrote:

> on 2/10/00 11:42 AM, costin@eng.sun.com <co...@eng.sun.com> wrote:
>
> > Hi,
> >
> > There are 3 issues with implementing security:
>
> I feel pretty strongly that this should not be implemented in the servlet
> engine. It should be implemented in the framework that you use.
>
> That is why I came up with Turbine in the first place. It gives you the
> ability to implement security any way that you want very easily.
>

However, in order to conform to the servlet spec 2.2 requirements, this
stuff *must* be implemented within the servlet container.  Thus, the issue
of how to do so remains.

Also, if you have a 2.2 container that supports this, you no longer have to
worry about it at the application level at all ...

>
> -jon
>

Craig

Re: Security in tomcat

[co...@eng.sun.com]

> > Hi,
> > 
> > There are 3 issues with implementing security:
> 
> I feel pretty strongly that this should not be implemented in the servlet
> engine. It should be implemented in the framework that you use.
> 
> That is why I came up with Turbine in the first place. It gives you the
> ability to implement security any way that you want very easily.

I agree we shouldn't try to do anything fancy in tomcat ( like defining
too many security APIs, etc). Tomcat is a servlet engine, not a security
provider, and we should keep security APIs outside tomcat.

We just need to have "adapters" to plug into various authentication APIs,
either generic like PAM or LDAP or frameworks that implement security
like Turbine. There are many arguments for that. 

I can't see any API that we might need to "bridge" external security APIs
to tomcat - the authentication happens before the invocation, in a
RequestInterceptor, and there is nothing we need to do after that. The
sec. interceptor(s) will set the authenticated user and roles, plus any
security informations ( isSecure, etc).

Tomcat needs to do the access control based on security-constraints (
authorization). ( that's required and we can't use Turbine for that :-).

Probably Craig's File Realm is enough for a mini-security realm, I'll try
to update it and add it ( make it work with current code, it seems to be
easy ).

Costin
 

Re: Security in tomcat

[jon * <jo...@clearink.com>]

on 2/10/00 11:42 AM, costin@eng.sun.com <co...@eng.sun.com> wrote:

> Hi,
> 
> There are 3 issues with implementing security:

I feel pretty strongly that this should not be implemented in the servlet
engine. It should be implemented in the framework that you use.

That is why I came up with Turbine in the first place. It gives you the
ability to implement security any way that you want very easily.

-jon

-- 
Come to the first official Apache Software Foundation
Conference!  <http://ApacheCon.Com/>