[Lenya Wiki] Update of "AuthenticationAndAuthorizationBackgrounder" by WasMax

[Apache Wiki <wi...@apache.org>]

Dear Wiki user,

You have subscribed to a wiki page or wiki category on "Lenya Wiki" for change notification.

The following page has been changed by WasMax:
http://wiki.apache.org/lenya/AuthenticationAndAuthorizationBackgrounder

------------------------------------------------------------------------------
  
  This document is supposed to be a tutorial style introduction into Authentication and Authorization in Lenya. It it meant to help understand the existing document AccessControl for those who might not yet have a detailed background of Authentication and Authorization in general and how these topics are handled by HTTP applications, servlet containers, Cocoon and Lenya in particular.
  
- = Lenya Authentication Walkthrough =
+ = Lenya Authentication and Authorization Walkthrough =
  
  == The Cocoon Sitemap in Lenya ==
  
@@ -54, +54 @@

  
  As you can easily tell from the Java package name org.apache.lenya.cms.cocoon.acting this is where Cocoon hands over to Lenya code for the first time. 
  
+ 
+ == Authentication ==
+ 
+ Authentication is process of confirming a user is who it claims to be. This is usually acheved in logging-in 
+ process (supplying username and password and checking it against database) process.
+ This is handled in special pipeline by {{{AuthenticatorAction}}}.
+ 
- == The DelegatingAuthenticatorAction supplied by Lenya ==
+ === The DelegatingAuthenticatorAction supplied by Lenya ===
  
  The class org.apache.lenya.cms.cocoon.acting.DelegatingAuthenticatorAction implements a Cocoon action which will handle the entire Lenya user authentication (read: login) process.
  
@@ -74, +81 @@

  
  As the Delegating... in the classname suggests all this piece of code does is to find out what AccessController is configured for this case and delegate the job there, just reporting back the result. This is where the Cocoon / Avalon concept of '''Inversion of Control''' comes to play. The Cocoon configuration will be used internally to decide which class should actually perform the action thus determining against what the user should be authenticated (file == default | other such as LDAP, JAAS, ... yet to be implemented).
  
- == Declaring the Authenticator in Lenya's cocoon.xconf configuration file ==
+ === Declaring the Authenticator in Lenya's cocoon.xconf configuration file ===
  
  In WEB-INF/cocoon.xconf there is a line declaring that if someone is looking for a role called ''org.apache.lenya.ac.Authenticator'' this will be implemented by the class ''org.apache.lenya.ac.impl.UserAuthenticator'':
  
@@ -92, +99 @@

  public boolean authenticate(AccreditableManager accreditableManager, Request request)
  }}}
  
+ This is common method for all authenticators.
+ Currently only the UserAuthenticator is implemented, and it delegates authentication to its specific method:
- Though this is very easy from the outside, having a look at '''how''' the UserAuthenticator makes its decision will help to understand more of the components that are involved. So let's dig a bit deeper into the above method.
- 
- '''Internal Note: ''' The author does not yet understand what the Identity object is all about that is beeing established and the user added to it inside UserAuthenticator. Therefore it is silently ignored here for now. Anyone is welcome to add this piece.
- 
- The core operation again can be found in two lines of code:
- 
  {{{
+ protected boolean authenticate(AccreditableManager accreditableManager, String username, String password, Identity identity)
- User user = accreditableManager.getUserManager().getUser(username);
- // ...
- if (user != null && user.authenticate(password)) {
-     // Do the stuff with Identity that I don't yet undertand
-     // ...
- }
  }}}
  
- The AccreditableManager's UserManager will be asked for a User object that machtes the given username. It will then ask that User object if it can authenticate the password. That's all.
+ This method then retrieves User object from accreditableManager and calls to User.authenticate(password).
+ If it passes, User object then stored in Identity - an object stored in session.
+ Identity stores all things that could be used to identificate (and authorize) request, these are: remote host IP, user name, and World. They are called Accreditables and used by AccessController to authorize request.
  
- == Publication - UserAuthenticator - AccreditableManager ==
+ == Authorization ==
  
- A publication is the starting point for Authentication and Authorization, because Authentication and Authorizaton might be publication specific. In other words: Two publications inside the same instance of Lenya may use entirely different mechanisms to authenticate and authorize the users.
+ Authorization is process of determining whether current request is allowed.
+ Authorization takes in account what url is requested, what usecase performed, etc.
+ This process is performed by {{AuthorizerAction}}}.
  
- ''(Put some more details in about config/ac.xconf, WEB-INF/cocoon/cocoon.xconf and the AccreditableManager.)''
+ === The DelegatingAuthorizerAction ===
  
+ This is another action used to check if requested resource, usecase or action is allowed during current request.
+ {{{DelegatingAuthorizerAction}}} uses avalone stuff to get AccessControllerResolverSelector, to select the only implemented AccessControllerResolver, which can at last return {{{AccessController}}}, responsible to grant access for requested url (IIRC). 
  
+ There are 1.5 AccessControllers described at http://lenya.apache.org/1_2_x/components/accesscontrol/accesscontrollers.html
+ 
+ The {{{DefaultAccessController}}} tries to authorize request with each of configured authorizers, calling {{{Authorizer.authorize(request)}}}.
+ Authorizers are described at http://lenya.apache.org/1_2_x/components/accesscontrol/authorizers.html
+ and configured in ac.xconf
+ 
+ === Accreditables, Identity and Authorizers ===
+ 
+ Accreditables are objects that can be used to gain access: {{{Users}}}, {{{Groups}}}, networks ({{{IPRanges}}}). These are used by {{{AccessController}}} to assign roles to request. 
+ {{{Machines}}} are another accreditables, but they need not to be managed, and got accredited through {{{IPRanges}}}.
+ 
+ {{{Identity}} object is stored in session and contains all accreditables associated with request.
+ Assigned accreditables are: World (special notion of 'all'), remote host IP and logged user.
+ 
+ When {{{AccessController}}} authorizes request, each selected authorizer takes {{{Accreditables}}} from session, and for every item determines roles and assigns them to processing request.
+ Each {{{Authorizer}}} has it's own implementation of method {{{.authorize(request}}} (egg using config files, policies or more hairy things).
+ 
+ Actually, authorizers check not for items itselves, but for associated {{{Accredetables}}}, got via {{{accreditable.getAccreditables()}}} callen for each item.
+ For users returned accreditables are user itself and associated groups. 
+ For hosts they are networks hosts belongs to.
+ 
+ After all authorizers assigned roles, Lenya finally has roles for current request and can determine if requested operation is permited. (Each operation is permited if request has specific roles, hard-coded or configured.)
+ 
+ == AccreditableManager ==
+ 
+ {{{AccreditableManager}}} is responsible to manage Accreditables :).
+ 
+ {{{Roles}}} themselves are also handled by AccreditableManager, althoug Roles are not accreditables, and generaly sayng, need not to be managed.
+ 
+ The only function of ''AccreditableManager'' is to provide instances of ''(User|Group|IPRange|Role)Manager''s, associated with common configuration. 
+ There could be several AccreditableManagers in system (egg. associated with different config directories), but their behaviour seems to be unpredictable ''''FIXME''''.
+ 
+ These ''*Manager''s provides access to actual users/groups/etc database and is used to tretrieve/store/delete/create Accreditables.
+ 
+ = AC framework Configuration =
+ 
+ All components 'deployment' is both in cocoon.xconf and lenya.roles.
+ This is global components configuration.
+ 
+ The {{{PublicationAccessControllerResolver}}} is configured in file {{{$path_to_pub/config/ac/ac.xconf}}}
+ (location of file is hardcoded). So, it provides publication-specific configuration.
+ 
+ The {{{ConfigurableAccessControllerResolver}}} is configured in cocoon.xconf with structures
+ similar to ac.xconf inside {{{<component-instance>}}} element.
+ 
+ All this stuff is described at http://lenya.apache.org/1_2_x/components/accesscontrol/
+ For all configuration directives assume them inside ac.xconf or {{{<component-instance>}}} for {{{ConfigurableAccessControllerResolver}}}.
+ 

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org