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

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:

<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.