Extended Access Control Lists (EACLs) extend the conventional ACL concept by allowing one to specify conditional authorization policies. These are implemented as conditions on authentication and authorization credentials. An EACL is associated with an object and lists the subjects allowed to access this object and the type of granted access. For example, the following EACL implements policy stating that anyone authenticated by Kerberos.V5 has read access to the targeted resource and any member of group 15 connecting from the USC.EDU domain has read and write access to the object.
| Token Type: access_id_ANYBODY | ||
| Defining Authority: none | ||
| Value: none |
| Token Type: pos_access_rights | ||
| Defining Authority: local_manager | ||
| Value: FILE:read |
| Token Type: authentication_mechanism | ||
| Defining Authority: system_manager | ||
| Value: kerberos.V5 |
| Token Type: access_id_GROUP | ||
| Defining Authority: DCE | ||
| Value: 15 |
| Token Type: pos_access_rights | ||
| Defining Authority: local_manager | ||
| Value: FILE:read FILE:write |
| Token Type: location | ||
| Defining Authority: system_manager | ||
| Value: *.USC.EDU |
The framework supports various strengths of user authentication mechanisms. A user may be granted a different set of rights, depending on the strength of the authentication method used for identification. Specification of weaker authentication methods including network address or username will allow the GAA API to be used with any existing application that does not have support for strong authentication.
The objects that need to be protected include files, directories, network connections, hosts, and auxiliary devices, e.g. printers and faxes. An authorization mechanism supports these different kinds of objects in a uniform manner. The same EACL structure can be used to specify access policies for different kinds of objects. Object names are drawn from the application-specific name space and are opaque to the authorization mechanism. When aprotected object is created, it requires the association of an EACL. The management of EACLs, including giving authority to modify EACL, is supported through inclusion of entries specifying which principals are allowed to modify the EACL. The control permissions comprise a separate set of access rights named with the tag MANAGEMENT. To restrict the ability to pass the control permissions to others a condition no_delegation can be specified.