Next: Query parameters
Up: Authorization Manager
Previous: Authorization Manager
The Authorization Manager is organized as a collection of Policies.
Each Policy contains in turn two sections: one mandatory
AttributeRepository and one optional Translation.
An AttributeRepository associates a subject DN to a set of attributes.
A Translation associates an attribute to a local-ID.
The semantic of the Authorization Manager accommodates the association of
several attributes to one subject, since a subject may play several
different roles. Each attribute may then be associated to a local-ID.
The final result of the authorization check is therefore the set of local-IDs
associated to the given subject DN.
Figure:
Authorization Manager structure
2#2
|
The Authorization Manager can be configured with several policies, typically
one for each target web application. One of the policies is defined as the
``default'' policy, i.e. the policy to be used when the incoming request does
not specify which policy must be used to authorize the client.
An AttributeRepository is built in one of the following way:
- and
- gets the information by and-ing a group of sub-repositories.
A client is authorized if it is associated with the same attribute in
all the sub-repositories.
- or
- gets the information by or-ing a group of sub-repositories.
A client is authorized if it is associated with one attribute in any of
the sub-repositories.
- voms
- gets the information from the VOMS extension of the client
certificate.
- map
- gets the information from an AttributeMap.
A Translation always gets the information from an AttributeMap.
An AttributeMap is a pluggable storage module where the associations are
stored and looked-up. It is implemented as a regular java.util.Map,
with some restrictions in usage and some convenience functions:
- Ordering of input must be reflected, i.e. if the AttributeMap is
read from a file and key A is listed before key B in that file, such an
ordering should be preserved (implementor's note: this is easily fixed by
implementing everything on top of java.util.LinkedHashMap).
- The key is always a String.
- The value is always a java.util.List of attributes.
- The AttributeMap must never return null on a get()
operation, instead an empty list should be returned.
Currently AttributeMaps are implemented in the following types:
- file
- gets the associations from a file. File formats currently
supported are gridmap, flat files and XML.
- db
- gets the association from a database. The only database currently
supported is MySQL.
- table
- gets the associations from the configuration file itself. This
type of AttributeMap stores only static associations that can not be modified.
- cached
- operates on top of another AttributeMap, caching lookup results
for faster future accesses.
- regex
- operates on top of another AttributeMap, interpreting the keys
as regular expressions.
Summary of Authorization Manager internal elements:
Element |
Type |
Policy |
|
|
- And |
AttributeRepository |
- Or |
|
- VOMS |
|
- Map |
Translation |
- Map |
|
- file (gridmap, flat file, xml) |
|
- db (MySQL) |
AttributeMap |
- table |
|
- cached |
|
- regex |
Next: Query parameters
Up: Authorization Manager
Previous: Authorization Manager
2004-07-02