tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Arkin <>
Subject Re: more stuff on JAAS
Date Mon, 17 Apr 2000 19:39:06 GMT wrote:
> Assaf Arkin wrote:
> >>> which puts it at a conflict with Jakarta policies.
> >>
> >> What policies are these?
> >
> >Use the relevant Java APIs.
> In my humble opinion, you may be imagining an issue that does not exist.
> That's why I want to help track it down.  Please help me help you.


Let's just look at what we have, see what makes sense and how to

* What should Tomcat include:

- Just enough to do LDAP authentication.

- Also LDAP-based authorization, maybe some more.

- As much as possible.

* Authentication vs Authorization:

- LDAP authentication: see if user name matches password. Requires
mapping of user name to DN submitting compare method to LDAP server.
Trivial to implement, efficient, does not require JAAS (or benefit from

- LDAP authorization: obtains additional information from the LDAP
server including other credentials, J2EE roles, full name, e-mail, etc.
Could benefit from a generic architecture like JAAS.

- Other forms of authentication: X509 client certificate validation and
LDAP authentication of it.

- Other forms of authorization: Kerberos, ERP connectors, mapping and
masquerading, auditing, etc.

* Which LDAP service provider to use:

JNDI Pros: The official JavaSoft API for directory access. Consistent
across other sources (file system, naming context, etc).

JNDI Cons: A bit too generic for a specific problem (LDAP), adds
overhead, possibility of more installation problems/bugs.

Mozilla Pros: Open source, stable release 4.0, well documented,
time-tested API, full LDAP v2/v3 capabilities, utility packages,
efficient, connection pooling, probably more stuff I missed.

Mozilla Cons: Only applies to LDAP, dependency on a particular
implementation package.

* How to use (or not) JAAS:

- Ignore it. Just get LDAP authentication working using the existing
security provider API. Cuts on the overhead introduced by the generic
JAAS architecture.

- Use it. Requires JDK 1.3.

- Replace it. Get most of the functionality available from a lookalike
API and use it until JAAS can be supported in 1.2.

- Replace it. Create a new API that can also work on Java 1.1, re-review
position towards JAAS in the future.



> As an example, a few months ago, I came timidly came forward with the
> recommendation that we include some code which a colleague of mine had
> written which, among other things, integrates Tomcat with Microsoft IIS.  I
> quite frankly wasn't sure what welcome I would receive, this being a Java
> centric crowd, Tomcat being a reference implementation, and Microsoft not
> typically being held in high regard by either the Java or Open source
> communities.
> And I wasn't prepared for the warm and enthusiastic reaction that this
> suggestion received.  In fact, shortly thereafter, another Jakarta
> committer nominated the originator of the code as a comitter, and this was
> ratified in short order.
> What I take from this is that anything which is not part of the core (i.e.,
> is pluggable), and pertains to the normal operation of Tomcat as a part of
> a web server, and may be of use to others is a fair topic for discussion.
> Note that I am a member of the Jakarta PMC, and a member of the Apache
> Software Foundation; and if necessary I will help make policies.  But quite
> frankly, to date I have never found this to be necessary, and I would be a
> bit surprised if it happened here.
> - Sam Ruby
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

Assaf Arkin                                 
CTO, Exoffice Technologies, Inc.              

View raw message