From commits-return-12333-apmail-directory-commits-archive=directory.apache.org@directory.apache.org Sun Feb 04 23:03:32 2007 Return-Path: Delivered-To: apmail-directory-commits-archive@www.apache.org Received: (qmail 97634 invoked from network); 4 Feb 2007 23:03:31 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2) by minotaur.apache.org with SMTP; 4 Feb 2007 23:03:31 -0000 Received: (qmail 69827 invoked by uid 500); 4 Feb 2007 23:03:38 -0000 Delivered-To: apmail-directory-commits-archive@directory.apache.org Received: (qmail 69772 invoked by uid 500); 4 Feb 2007 23:03:38 -0000 Mailing-List: contact commits-help@directory.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@directory.apache.org Delivered-To: mailing list commits@directory.apache.org Received: (qmail 69761 invoked by uid 500); 4 Feb 2007 23:03:37 -0000 Delivered-To: apmail-incubator-directory-cvs@incubator.apache.org Received: (qmail 69758 invoked by uid 99); 4 Feb 2007 23:03:37 -0000 Received: from herse.apache.org (HELO herse.apache.org) (140.211.11.133) by apache.org (qpsmtpd/0.29) with ESMTP; Sun, 04 Feb 2007 15:03:37 -0800 X-ASF-Spam-Status: No, hits=-0.0 required=10.0 tests=SPF_HELO_PASS X-Spam-Check-By: apache.org Received: from [140.211.11.130] (HELO eos.apache.org) (140.211.11.130) by apache.org (qpsmtpd/0.29) with ESMTP; Sun, 04 Feb 2007 15:03:30 -0800 Received: from eos.apache.osuosl.org (localhost [127.0.0.1]) by eos.apache.org (Postfix) with ESMTP id 52EAA5A1CF for ; Sun, 4 Feb 2007 23:03:10 +0000 (GMT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: Apache Wiki To: directory-cvs@incubator.apache.org Date: Sun, 04 Feb 2007 23:03:10 -0000 Message-ID: <20070204230310.11768.55083@eos.apache.osuosl.org> Subject: [Directory Wiki] Update of "AuthXHome" by CKoppelt X-Virus-Checked: Checked by ClamAV on apache.org Dear Wiki user, You have subscribed to a wiki page or wiki category on "Directory Wiki" for change notification. The following page has been changed by CKoppelt: http://wiki.apache.org/directory/AuthXHome The comment on the change is: moved to http://cwiki.apache.org/DIRxSBOX/authx.html ------------------------------------------------------------------------------ + deleted - ## page was renamed from JanusHome - == About AuthX == - AuthX is an effort to develop an Authentication, Authorization and Accounting framework for - building security infrastructures. - - == Objectives == - - AuthX primary objective is to provide a framework for integrating AAA into applications in a cost-effective manner. - - To attain this objective, AuthX attempts to deal with the following: - - * Flexible authentication mecanism with open authentication methods - * Powerful and extensible authorization model - * Built-in Accounting/Auditing - * Non intrusive POJO model, IoC friendly - - == What AuthX is not == - - AuthX is not an integrated, out-of-the-box security solution. It is rather a framework on top of which plug-and-play solutions can be built. - - For instance, one could decide to build a User Management solution offering username/password authentication and Role-Based access control on top of AuthX. A complete solution would probably offer different alternatives for dealing with passwords, a range of persistnce storage to choose from (DB, LDAP, ...), and a set of interceptors and web filters to apply security declaratively. - - Another potential security solution that could be built on top of AuthX is a JAAS implementation. - - Nevertheless, AuthX aims to provide building blocks for such solutions, such as LDAP or Database realms access. That said, some concerns will remain out of the scope of AuthX. For example, a concern that AuthX will probably never address if the management of security data (e.g. adding users to realms or modifying passwords). - - As such, the domain model of AuthX is defined in terms of Subjects, Principals, Credentials and Permissions rather than Users or Groups or Roles. This is why where possible, AuthX tries to leverage the standard Java definition of those security concepts. - - == Glossary == - - ||'''Credential'''||Unit of proof of identity|| - ||'''Realm'''||A set of credentials with an associated authentication method|| - ||'''Subject'''||Result of a successful authentication|| - ||'''Authenticator'''||Renders an authentication result|| - ||'''Resource'''||Object of an authorization decision|| - ||'''Action'''||Operation to be performed on a resource|| - ||'''Permission'''||An action on a resource which is the subject of an authorization decision|| - ||'''Condition'''||An expression of predicates on a subject (on its principals)|| - ||'''Rule'''||Definition of an effect of verifying a condition on a permission|| - ||'''Effect'''||Consequence of evaluating a rule that participates in an authorization decision: permit, deny, indeterminate|| - ||'''Policy'''||A set of rules and an algorithm for combining rules|| - ||'''Policy Set'''||A set of policies (or other policy sets) and an algorithm for combining policies|| - ||'''Context'''||A set of environmental attributes that affects an authorization decision|| - ||'''Information Provider'''||Provides information on subject attributes (e.g. groups, roles)|| - ||'''Authorization decision'''||Result of evaluating policies: permit or deny access|| - ||'''Authorizer'''||Renders an authorization decision based on policies/or policy sets|| - - == Overview of the Security Model == - - The security process aims at protecting sensitive resources from unauthorized access. This is done with a combination of authentication - to prove an individual's identity -, and authorization - to grant or deny an operation on a resource. - - Follows a representation and description of the security flow. - - === Authentication === - - Authentication is the first part of the security flow. - - Authentication is the process of validating an individual's identity. It's about finding out if an individual is who he/she claims to be. This is done by presenting some proof of identity, which usually can take the form of username/password, digital signature, etc. The idea is that each individual can be recognized by unique information that differentiates him or her from other individuals. - - The ''Authenticator'' role is to render authentication result, based on information provided by individuals in the form of a ''CredentialSet''. A ''CrendentialSet'' is a set of proofs of identity, i.e. ''Credential'' objects. - - Typically, the ''Authenticator'' will validate the authentication request against one or more ''Realm''s. Successful validation will authentify the individual and identify it with a ''Principal''. - - After authentication, optional additional information on the individual is retrieved from ''InformationProvider''s, to complete the description of the individual. - - The overall result of the authentication decision is a ''Subject'' object. - - {{{ - credentials - Client ----------------------------> credentials - authentication request -------------------> - Realm (validates credentials) - <------------------- - Principal - - Authenticator - - Subject - ------------------> - Information Provider - (describes Subject with additional attributes) - <------------------ - Subject Subject (with attributes, e.g. group or roles) - <---------------------------- - authentication result - }}} - - === Authorization === - - Authorization is the second part of the security flow. - - Authorization is about, once a user has been authenticated, determining if he/she is authorized to do something. A successful authorization results in the user being granted the permission to perform an operation on a resource. A failed authorization will result in the denial of the same permission. - - Rendering authorization decision is the responsibility of the ''Authorizer''. Typically, this is done by evaluating a number of conditions both on the requester of the permission (the subject), and the permission requested (the permission). AuthX conditions and their effects are called authorization rules. - - During the authorization process, the authorization request is evaluated against one or more ''Policies''. Each ''Policy'' defines a set of rules to evaluate, each resulting in a negative, positive or abstain vote. The result of evaluating the authorization request against a ''Policy'' is computed based on a policy specific algorithm. - - The Authorizer finally renders the authorization decision based on the results of all applicable policies evaluation. - - {{{ - Subject + Permission - Client ----------------------------> - authorization request Subject + Permission - -------------------------> - Policy (or policy set) - (evaluates contained rules) - <------------------------- - Effect (combination of applicable rules effects) - - Authorizer (repeat for all policies) - - ------- - | Renders authorization decision - <------ - <----------------------------- - Authorization decision - }}} - - == Authorization Rules == - - AuthX introduces a rule based system to implement authorization. Rules - are much more flexible than what you can do with an RBAC system. In fact - a rule is anything that implements the Rule interface (no surprise - here): - - {{{ - Rule { - void evaluate(AuthorizationRequest request); - } - }}} - - It's very easy to implement RBAC using AuthX rule mechanism. It's a - matter of defining a set of rules that authorize access to a resource if - a subject has a given principal - for instance , a specific principal that represents - a role. But you can do much more with rules. - - The way you define your rules is pluggable in AuthX, and 2 mechanisms - are provided out-of-the box. - - === XML === - The first one is to use an XML document. AuthX provides a - builder to be parse and interpret your XML document. This means AuthX - needs to know how to deal with the XML elements. A set of XML - elements are understood out of the box, such as: - - , , , , , , , , - , ... and you mix them to express your authorization logic. - - Furthermore, you can plug your own element interpreters. - This is useful to represent your permissions, which - are typically application dependent. - - XML is fine, but it lacks the power of expressing more complicated needs - and for every XML element you introduce, there need to be an interpreter - that undertands it's meaning. That is somewhat limitating and AuthX - wants to support of wide range of authorization systems. - - This is where the scripted rules comes into play. - - === Dynamic Language === - Using groovy (in the future, we could support other scripting - languages, such as rhino, beanshell, pnuts, ...) to define rules is much - more powerful. Just implement the rule interface and code what you need. - I believe this is the best way to allow any kind of logic to be plugged - into the authorization subsystem. - - For example, if we want to grant any permissions to canadian people, we - would write it like this in XML: - - {{{ - - - - canadians - - - - - - - }}} - - And like this in groovy: - - {{{ - class GrantCanadiansAnythingRule { - - def evaluate( request ) { - def canadians = new GroupPrincipal("canadians") - if (request.getSubject().getPrincipals().contains(canadians)) - request.grant() - } - } - }}} - - Using a scripted language is much more powerful than using XML. - One could envision defining its own domain specific language, - write the script interpreter for it and let security officers write - the security rules themselves. -