directory-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Apache Wiki <wikidi...@apache.org>
Subject [Directory Wiki] Update of "AuthXHome" by VincentTence
Date Wed, 14 Dec 2005 04:29:05 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:
http://wiki.apache.org/directory/AuthXHome

------------------------------------------------------------------------------
  ## page was renamed from JanusHome
- === About AuthX ===
+ = About AuthX =
  
  AuthX is an effort to develop an Authentication, Authorization and Accounting framework
for
  building security infrastructures. AuthX is the security sub-project for the Eve directory
server.
  
- ==== Glossary ====
+ = Glossary =
  
  ||'''Credential'''||Unit of proof of identity||
  ||'''Realm'''||A set of credentials with an associated authentication method||
@@ -25, +25 @@

  ||'''Authorization decision'''||Result of evaluating policies: permit or deny access||
  ||'''Authorizer'''||Renders an authorization decision based on policies/or policy sets||
  
- ==== Control Flow ====
+ = Control Flow =
  Based on the above definitions, follows a representation of the security flow:
  
  '''Authentication'''
@@ -69, +69 @@

              Authorization decision
  }}}
  
+ == Authorization Explained ==
+ 
+ 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
+ RolePrincipal. 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.
+ 
+ 1. 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.
+ 
+ 2. 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 {
+ 
+    evaluate( request ) {
+        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.
+ 

Mime
View raw message