Return-Path: Delivered-To: apmail-directory-users-archive@www.apache.org Received: (qmail 50898 invoked from network); 16 Mar 2005 22:26:18 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (209.237.227.199) by minotaur-2.apache.org with SMTP; 16 Mar 2005 22:26:18 -0000 Received: (qmail 57416 invoked by uid 500); 16 Mar 2005 22:26:18 -0000 Delivered-To: apmail-directory-users-archive@directory.apache.org Received: (qmail 57393 invoked by uid 500); 16 Mar 2005 22:26:17 -0000 Mailing-List: contact users-help@directory.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: users@directory.apache.org Delivered-To: mailing list users@directory.apache.org Received: (qmail 57380 invoked by uid 99); 16 Mar 2005 22:26:17 -0000 X-ASF-Spam-Status: No, hits=0.4 required=10.0 tests=DNS_FROM_RFC_ABUSE,FORGED_RCVD_HELO X-Spam-Check-By: apache.org Received-SPF: pass (hermes.apache.org: local policy) Received: from relais.videotron.ca (HELO relais.videotron.ca) (24.201.245.36) by apache.org (qpsmtpd/0.28) with ESMTP; Wed, 16 Mar 2005 14:26:14 -0800 Received: from agilis.homelinux.com ([66.131.110.157]) by VL-MO-MR010.ip.videotron.ca (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep 8 2003)) with ESMTP id <0IDG00286UA4DS@VL-MO-MR010.ip.videotron.ca> for users@directory.apache.org; Wed, 16 Mar 2005 17:25:17 -0500 (EST) Received: from 207.236.211.119 (SquirrelMail authenticated user tom) by agilis.homelinux.com with HTTP; Wed, 16 Mar 2005 17:24:42 -0500 (EST) Date: Wed, 16 Mar 2005 17:24:42 -0500 (EST) From: Vincent Tence Subject: RE: AuthX information In-reply-to: To: Minggui_Chen@ibi.com Cc: users@directory.apache.org Message-id: <18432.207.236.211.119.1111011882.squirrel@agilis.homelinux.com> MIME-version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT Importance: Normal X-Priority: 3 (Normal) User-Agent: SquirrelMail/1.4.4 References: X-Virus-Checked: Checked X-Spam-Rating: minotaur-2.apache.org 1.6.2 0/1000/N > I did check out the policy.xml and permissions.xml from the source and > read more api in order to understand more. I list my understandings here > in case that I might have made it wrong: > (1) The rule set (permissions) could be created initially from xml; This is indeed one way to do it. The other one is to define your rules in groovy (other scripting languages could be added, such as beanshell, pnuts, rhino). > (2) The rule set could be updated dynamically through Policy class; Correct. > (3) All the rules should be loaded in memory (?) Currently yes > (4) Every entry in every Access Control List is a rule. Close enough > Based on that, here is my concerns: > (1) If there is a rule conflict, for example: > "/a/" contains many subfolders, if I define a rule as: > User1 could read "/a/*", > but User1 could not read "/a/b/*", > what will happen? Rules are packaged in a group known as a ruleset, which uses a conflict resolution algorithm. The following algos are provided: - PermitOverrides: permit overrides any other decision - DenyOverrides: deny overrides any other decision - LastApplicable: the last permit or deny wins - FirstApplicable: the first permit or deny wins > (2) If I have to support user based access control list (not just role > based), I might have to define many rules. You could also use groups. > That could cause a memory > problem if I have to load all rules into the memory. There should be one > way to load only a small part (caching) from the repository dynamically. That could be an interesting addition indeed. > (3) How could I dynamically sync rule set with permission repository such > as a file or a DB? Currently there's no support for storing rules in BD. As for files, it's easy to do if your rules are written in groovy. We could provide an implementation of the RuleSet that you feed with script urls instead of rule objects. At runtime, whenever the script file has changed, the rule would be reloaded (there's already support automatically reloading groovy scripts). If you use XML definitions, we could put up an implementation of the Authorizer that checks at runtime if the xml file has changed and reloads the rule set accordingly. > (4) There seems no direct relation with LDAP. Will ApacheDS use it and > how? Next step for AuthX is to use ApacheDS as a storage mechanism and use AuthX as the server's internal Authentication and Authorization framework. > We really like the project and hope we could use it I'm delighted to read that. Thanks for your interest! >, so I have to ask you > a lot stupid questions. I wish you will not mind. Thank you for your kind > help. There aren't any stupid questions. Don't hesitate to ask. I suggest you subscribe to users@directory.apache.org (send a empty mail to users-subscribe@directory.apache.org), so that we can discuss that on the list. Cheers, -- Vincent > Minggui > > > > -----Original Message----- > From: Vincent Tence [mailto:vtence@videotron.ca] > Sent: Wednesday, March 16, 2005 2:11 PM > To: Chen, Minggui > Subject: Re: AuthX information > > >> Vincent: >> >> Please pardon me for sending mail directly to you. I think I am >> bothering >> you a lot. But there is no way for me to get the answer from apache. > > No worries. I'm not sure what you mean when you say there's no way to get > an answer from apache. Have you tried writing to the directory users list > ad users@directory.apache.org? This is our new mailing list for users now. > >> >> Currently we are very interested on the Apache directory project being >> developed by you guys, and we really appreciate your work. Since it is >> still in incubator, we are eager to know some information for our >> business >> decision. > > Thanks. We appreciate the fact that you're having interest in the project. > >> >> For now I can only guess to what extend AuthX is trying to do. My >> understanding is that it is a rule based framework. > > AuthX is an Authentication, Authorization and Accounting framework that > aims to help build security into Java application. With AuthX, is should > be easier and much cheaper to implement data driven security into an > application. Currently, the J2EE spec doesn't help much in terms of > authorization decisions that must be taken based on the data being > accessed as well as the identity and attributes of the subject. > > AuthX uses a rule-based authorization framework. Instead of being only > RBAC, it uses rules to describe security policy. With the rule approach, > building an RBAC system is straightforward, and more complex security > schemes are possible as well. > >> OK, but do I need to >> implement the interface to interpret the rule set or do I only need to >> define the rules through GUI or config file after AuthX is eventually >> finished? > > There's no GUI since AuthX is a framework. There could be supporting tools > at some point, but it's not the priority right now. > > There is 2 ways you can define your own rules: > > 1. Using an XML file. You can plug into the XML policy builder to use your > own grammar > 2. Using a scripting language such as groovy. You write your authorization > rules using groovy and load them using the provided framework classes. > This gives you greatest flexibility with min coding. > > There is an example application in the SVN source tree that can help you > understand how to use authx. Also, on the wiki, there's a general overview > of the concepts behind authx: > > http://wiki.apache.org/directory/JanusHome > > That's not much. Documentation is a major concern at this point, I realize > that. I'll be working on it. > >> I understand that it's going to support LDAP realm. But I am not sure if >> it is going to support LDAP authorization. Could you explain a little >> bit >> more? Such as its relationship with ACP and ACL? > > LDAP will be used as a storage mechanism for usernames/passwords, groups > and roles defintion. This feature is on the way. > >> Just curious if you could give me a suggestion. If I am going to use >> LDAP >> to support role based authorization, I am not sure if I should use LDAP >> ACL (and sure I have to write the code to implement the policy), or >> AuthX >> will solve the problem for me. > > If you look at the diagram on the wiki, you'll see that authorization > rules are separated from the concern of loading subject attributes (rules > or groups the user might belong to). Rules only use this information to > take decisions. Usernames, passwords, roles, groups are all meant to be > stored in a LDAP directory, but I don't see rules sitting there. Rules are > dynamic, application specific and subject to change. They'll more likely > reside in XML files or script files along with the application. > >> Your kind reply will be highly appreciated! > > Hope that help, > > -- Vincent > > P.S. Do you mind if I copy the directory users lists in order to help > other users as well? >