Mailing-List: contact tomcat-dev-help@jakarta.apache.org; run by ezmlm
Precedence: bulk
Reply-To: tomcat-dev@jakarta.apache.org
Message-ID: <3B45B696.59C1CECB@teamware.com>
Date: Fri, 06 Jul 2001 16:01:10 +0300
From: Antony Bowesman <adb@teamware.com>
MIME-Version: 1.0
To: tomcat-dev@jakarta.apache.org
Subject: Re: First day - RE: PROPOSAL:  Tomcat docs
References: <NEBBKCJBPLLPNFMKLPAJMEODDHAA.rslifka@home.com>
 <00eb01c104fe$32e24b20$3512a8c0@wspunkytse> <3B43EFA7.72B2AD53@teamware.com>
 <3B4453E5.C4EBC7BC@voyager.apg.more.net> <3B455E8E.AE3F1C40@teamware.com>
 <3B45B16F.19374236@voyager.apg.more.net>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Glenn,

Glenn Nielsen wrote:
> 
> Antony Bowesman wrote:
> >
> > Glenn Nielsen wrote:
> > >
> > > Antony Bowesman wrote:
> > > >
> > > > > 8. Security
> > > >
> > > > How about
> > > > 8.1 Concepts - Explanation of J2EE and Java 2 security models
> > > > 8.2 Authentication with Realms
> > > > 8.2.1 Simple realm
> > > > 8.2.2 JDBC Realm
> > > > 8.2.3 Custom realms
> > > > 8.3 Authorization
> > > > 8.3.1 J2EE role based
> > > >
> > > > In particular, it should try to explain in simpler terms than the API
> > > > spec how J2EE roles are designed to work, covering the mapping from
> > > > developer roles to deployment roles.
> > > >
> > > > 8.3.2 Java 2 security policy
> > > >
> > >
> > > I would break the above into two sections.
> > >
> > > Access Control (for all the Realm based access control)
> > >
> > > and
> > >
> > > Server Security (for configuring and using Tomcat with the Java
> > > SecurityManager)
> > >
> > > These really are two completely different topics.  And use of
> > > Realms isn't "Security", it is "Access Control".
> >
> > Not sure I'd agree with your removal of Java Security Manager from a
> > chapter about access control.  The first line of the JavaTM 2 Platform
> > Security Introduced: document at
> >
> > http://java.sun.com/j2se/1.3/docs/guide/security/index.html
> >
> > says
> >
> > * Policy-based, easily-configurable, fine-grained access control....
> >
> > Access control is one element of securing a server, as is
> > authentication, encryption, non repudiation, SSL etc.
> >
> > Access control is performed by Java 2 security manager as well as J2EE
> > and they compliment each other.  JAAS (JDK1.3 extension) which extends
> > the Java 2 model and which is now included in JDK1.4 extends the Java 2
> > security model to provide principal based access control on top of code
> > source.  So access control is firmly part of Java security.
> >
> > There should be additional sections on 'server security' that includes
> > configuring the server for use with SSL.
> >
> 
> I have seen the general term 'security' used instead of a more 
> descriptive term like SSL Encryption, SecurityManager, or Access
> Control.  My point is that these are very different things, and
> the documentation should be constructed so that users use those
> terms rather than the general term "Security".

Yes, I agree there are different elements of security, I don't agree
that access control is different to security manager.  The difference is
that java 2 security, i.e. security manager, is different to J2EE role
based access control.

> Security
>   Overview - types of security
>   J2EE Security Model
>   User Access Control (Realms & roles)
>   Java SecurityManager
>   SSL Data Encryption
> 
> Yes, JAAS can be used to control access for executing code based
> on what role the user is in.  At this point there is no support
> in Tomcat for JAAS.

Not specifically, because the servlet API spec does not support it,
however, JAAS is on the list for servlet API spec 2.4 (who knows when
that might be!).  

However, I am currently using JAAS in Tomcat 3 and I know others have
JAAS running with tomcat (e.g. Jboss/Tomcat integration)

> There are two ways I see JAAS being used within Tomcat sometime in
> the future.
> 
>   1. Policy based JAAS access control to Tomcat's manager or admin 
>      servlet.
> 
>   2. Some Policy configuration tool for webapps that supports normal Java
>      SecurityManager configuration and JAAS policy based access control.

I suspect that when the API spec supports JAAS there will be some kind
of getUserSubject() method in the spec that gets the JAAS Subject and
the getUserPrincipal() will be deprecated because JAAS supports more
than a single Principal.

However, as SecurityManager uses the Java 2 security Policy it
effectively enable JAAS support as soon as JDK1.4 is released.  Tomcat
could therefore provide support for the JAAS Subject internally. 
However, I have seen other comments on this list that Tomcat is trying
to support many early versions of JDK so requiring JDK1.4 support might
be too difficult.

Anyway, SUN are asking for feedback about how JAAS should be implemented
in the servlet API spec, so send your comments there, I already have!

Rgds
Antony