directory-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Apache Wiki <>
Subject [Directory Wiki] Update of "AuthXHome" by CKoppelt
Date Sun, 04 Feb 2007 23:03:10 GMT
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:

The comment on the change is:
moved to

+ deleted
- ## page was renamed from JanusHome
- == About AuthX ==
- AuthX is an effort to develop an Authentication, Authorization and Accounting framework
- 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
- ||'''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
-                                                    <-------------------             
-                                                         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:
- <grant>, <deny>, <any>, <none>, <username>, <role>,
<group>, <and>,
- <or>, ... 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:
- {{{
- <policy>
-    <grant>
-        <subjects>
-            <group>canadians</group>
-        </subjects>
-        <permissions>
-            <any/>
-        </permissions>
-    <grant>
- </policy>
- }}}
- 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.

View raw message