Return-Path: Delivered-To: apmail-jakarta-tomcat-dev-archive@apache.org Received: (qmail 4497 invoked from network); 4 Dec 2002 19:21:26 -0000 Received: from unknown (HELO nagoya.betaversion.org) (192.18.49.131) by daedalus.apache.org with SMTP; 4 Dec 2002 19:21:26 -0000 Received: (qmail 11967 invoked by uid 97); 4 Dec 2002 19:22:24 -0000 Delivered-To: qmlist-jakarta-archive-tomcat-dev@jakarta.apache.org Received: (qmail 11943 invoked by uid 97); 4 Dec 2002 19:22:23 -0000 Mailing-List: contact tomcat-dev-help@jakarta.apache.org; run by ezmlm Precedence: bulk List-Unsubscribe: List-Subscribe: List-Help: List-Post: List-Id: "Tomcat Developers List" Reply-To: "Tomcat Developers List" Delivered-To: mailing list tomcat-dev@jakarta.apache.org Received: (qmail 11923 invoked by uid 98); 4 Dec 2002 19:22:23 -0000 X-Antivirus: nagoya (v4218 created Aug 14 2002) To: tomcat-dev@jakarta.apache.org X-Injected-Via-Gmane: http://gmane.org/ Path: not-for-mail From: Costin Manolache Subject: Re: [5] [Proposal] Adding an authorization interface Date: Wed, 04 Dec 2002 10:30:54 -0800 Lines: 37 Message-ID: References: <3DE53AD8.2000405@apache.org> <3DEE16A4.4030607@mail.more.net> NNTP-Posting-Host: 64.84.39.162 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7Bit X-Trace: main.gmane.org 1039026537 21501 64.84.39.162 (4 Dec 2002 18:28:57 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Wed, 4 Dec 2002 18:28:57 +0000 (UTC) User-Agent: KNode/0.7.1 Sender: news X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N Glenn Nielsen wrote: > There are a number of different types of realm implementations in > org.apache.catalina.realm. These are all solely used for web application > realm based authentication except for those which implement the > UserDatabase which understands users, groups, and roles and has methods > for managing these. Also a UserDatabase can be instantiated as a JNDI > resource. > > It would be nice if all realm implementations could support not only > authentication > and authorization but also management of users, groups, and roles. And be > instantiated as a JNDI resource so it can be provided by the container as > a resource to a virtual host. Requiring all realm implementations to support user management is not a good idea. Some realms can do that ( database, our own file, ldap) and some just can't ( passwd, kerberos/radius/tacacs, etc ). I think we have 3 distinct issues: - authorization: I think tomcat needs to expose a single hook and provide a default implementation ( using the mapper - it can also implement jsr115, but it needs to be efficient ) - authentication: again one hook that could be implemented by delegating to apache or use JAAS ( that should be the default - and all current Realms migrated to JAAS plugins ! ) - user management. That should be optional - and probably the best abstraction is JNDI. Besides user/pass/certificate it can store all other user attributes. I think we should be consistent on naming the attributes as in the inetUser LDAP schema ( it will work out-of-box with existing ldap servers and easy to translate to databases, etc ). All UserDatabase impl should be migrated to JNDI providers, and UserDatabase deprecated ( or implemented on top of jndi ). Costin -- To unsubscribe, e-mail: For additional commands, e-mail: