[Lenya Wiki] Trivial Update of "OverviewAuthenticationAndAuthorization" by JörnNettingsmeier

[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 JörnNettingsmeier:
http://wiki.apache.org/lenya/OverviewAuthenticationAndAuthorization

------------------------------------------------------------------------------
  return result;
  }}}
  
- 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).
+ 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] | LDAP | others such as JAAS [yet to be implemented]).
  
  === Declaring the Authenticator in Lenya's cocoon.xconf configuration file ===
  
@@ -122, +122 @@

  {{{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
+ '''FIXME: what is this mysterious half of an AccessController?'''
  
  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
@@ -129, +130 @@

  
  === 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. 
+ Accreditables are objects that can be used to gain access: {{{Users}}}, {{{Groups}}}, network ({{{IPRanges}}}). These are used by {{{AccessController}}} to assign roles to requests. 
- {{{Machines}}} are another accreditables, but they need not to be managed, and got accredited through {{{IPRanges}}}.
+ {{{Machines}}} are another type of accreditables, but they need not to be managed, and get 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.
+ Every session contains an {{{Identity}}} object, which contains all accreditables associated with the request.
+ These are: World (everybody owns this accreditable), 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.
+ When the {{{AccessController}}} authorizes a request, each selected authorizer takes {{{Accreditables}}} from the 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).
+ Each {{{Authorizer}}} has its own implementation of the {{{.authorize(request}}} method (e.g. 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.
+ Actually, authorizers do no check for items themselves, but for associated {{{Accreditables}}}, which are acquired via calls to {{{accreditable.getAccreditables()}}}  for each item.
- For users returned accreditables are user itself and associated groups. 
+ For users returned accreditables are user itself and the groups the user belongs to. 
- For hosts they are networks hosts belongs to.
+ For hosts they are the networks the host belongs to.
  
  === Authorizers ===
  

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