Return-Path: Delivered-To: apmail-jakarta-tomcat-dev-archive@apache.org Received: (qmail 81689 invoked from network); 28 Nov 2002 18:47:49 -0000 Received: from unknown (HELO nagoya.betaversion.org) (192.18.49.131) by daedalus.apache.org with SMTP; 28 Nov 2002 18:47:49 -0000 Received: (qmail 25312 invoked by uid 97); 28 Nov 2002 18:48:50 -0000 Delivered-To: qmlist-jakarta-archive-tomcat-dev@jakarta.apache.org Received: (qmail 25274 invoked by uid 97); 28 Nov 2002 18:48:49 -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 25260 invoked by uid 98); 28 Nov 2002 18:48:49 -0000 X-Antivirus: nagoya (v4218 created Aug 14 2002) Message-ID: <3DE66514.1060604@apache.org> Date: Thu, 28 Nov 2002 13:48:52 -0500 From: Jeanfrancois Arcand User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.2) Gecko/20021126 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Tomcat Developers List Subject: Re: [5] [Proposal] Adding an authorization interface References: <3DE53AD8.2000405@apache.org> <3DE5702E.9080500@apache.org> <3DE58086.6040309@apache.org> In-Reply-To: Content-Type: multipart/alternative; boundary="------------080207080305090806080303" X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N --------------080207080305090806080303 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Costin Manolache wrote: >Jeanfrancois Arcand wrote: > > > > >>>Why would someone use this instead of web.xml ? >>> >>> >>> >>Because you can start using the java.security.Provider.checkPermission >>for granting/denying resources. >> >> > >Not sure this would be the most efficient solution - the mapper is >( or will be ) optimized on the way it is used in tomcat. But I see >your point - and I think it would be nice to use similar concepts or >API. > > > > > >>>If by authorization you mean deciding in an URL can be accessed by a user >>>- I think the mapper ( or a similar valve ) is the best solution, using >>>the informations in web.xml. >>> >>> >>> >>Exactly. The "similar valve" :-) is the AuthenticatorBase, who delegate >>part of the authorization decision to the RealmBase, as well as part of >>authentication. I'm +1 to delegate the authentication to the RealBase, >>but -1 to delegate the authorization (this is how it is implemented >>right now). What I recommend is to remove the authorization code from >>the RealmBase and move it to the AutorizerBase. It's just refactoring >>one class into 2. Then we will be able to use JAAS (or 115, LDAP, NFS, >>etc.) in a "cleaner" way. >> >>Using JAAS as an interface will have to happen somewhere in >>AuthenticatorBase & RealmBase. Since in JAAS there is a clear separation >>between authentication/autorization, why not have the same separation in >>Tomcat by having Realm & Authorizer (instead of only Realm). >> >> > > >I agree that "authenticate" and "authorize" are 2 different hooks and need >to be separated. > >Let me think about it - and maybe get some other opinions. > >I would very much preffer a consistent mechanism for all the hooks in >tomcat. In 3.3 there is one interface ( BaseInterceptor ) where all >the possible hooks are defined ( with a number of problems we already >know regarding ordering, but that's a different issue ). In 4.x Valves >are used as the main extension mechanism, but also Listeners, Realms, >Connectors and few other interfaces - and I would very much prefer >a solution that is more consistent and simpler. > Just downloaded 3.3 code base. I will take a look at the way it work. I not familiar with 3.3 code base. > > >For example - move it at Coyote level and use an ActionCode for >authorization. Things are not very well defined for chaining the >coyote actions, but it can be done easily. > >All hooks could be defined as coyote Actions - instead of having a specific >Authorizer interface you'll have an authorizer action. > >Does it sound acceptable ? I would mention that this is how authorization >is implemented in apache ( and most web servers ), and it would probably >make it easier to integrate. > Let me learn in more detail the coyote stuff and think about it. I was trying to align the change with the current Valve/Realm implementation, but exploring other avenues for sure will help defining a better design. I will come back soon on the subject..... > >Well, there is just a style difference between having a generic hook >and having one specific interface like Authorizer, but for a lot of people >understanding the hook mechanism and the particular hooks is easier than >dealing with dozens of slightly different interfaces. > I agree. If It possible, I will come up with an ActionCode. If not, then we should use the Authorizer idea. Thanks, -- Jeanfrancois > > > >Costin > > > > > > > > > >-- >To unsubscribe, e-mail: >For additional commands, e-mail: > > > > --------------080207080305090806080303--