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 VincentTence
Date Wed, 14 Dec 2005 05:24:00 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 VincentTence:

  ## page was renamed from JanusHome
- = About AuthX =
+ == About AuthX ==
  AuthX is an effort to develop an Authentication, Authorization and Accounting framework
- building security infrastructures. AuthX is the security sub-project for the Eve directory
+ 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 and Groups and Roles and such. This is why where possible,
AuthX tries to leverage the standard Java definition of those security concepts.
- = Glossary =
+ == Glossary ==
  ||'''Credential'''||Unit of proof of identity||
  ||'''Realm'''||A set of credentials with an associated authentication method||
@@ -25, +48 @@

  ||'''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 ==
- = Control Flow =
- Based on the above definitions, follows a representation of the security flow:
- '''Authentication'''
+ 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.
  Client ---------------------------->                   credentials 
@@ -49, +88 @@

             authentication result  
- '''Authorization'''
+ === 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 ---------------------------->                   
@@ -69, +119 @@

              Authorization decision
- == Authorization Explained ==
+ == 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
@@ -90, +140 @@

  The way you define your rules is pluggable in AuthX, and 2 mechanisms
  are provided out-of-the box.
+ === XML ===
-  1. The first one is to use an XML document. AuthX provides a
+ 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:
@@ -109, +160 @@

  This is where the scripted rules comes into play.
+ === Dynamic Language ===
-  2. Using groovy (in the future, we could support other scripting
+ 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

View raw message