Extended Access Control Lists (EACLs) extend the conventional ACL concept by allowing specification of conditional authorization policies, implemented as restrictions on authentication and authorization credentials.
An EACL is associated with an object and lists principals allowed to access this object and the type of granted access. When an object to be protected is created, it requires the association of an EACL.
For example, the following EACL implements traditional ACL 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_identity_ANYBODY | ||
| Defining Authority: none | ||
| Value: none |
| Token Type: positive_access_rights | ||
| Defining Authority: local_manager | ||
| Value: FILE:read |
| Token Type: authentication_mechanism | ||
| Defining Authority: system_manager | ||
| Value: kerberos.V5 |
| Token Type: access_identity_GROUP | ||
| Defining Authority: DCE | ||
| Value: 15 |
| Token Type: positive_access_rights | ||
| Defining Authority: local_manager | ||
| Value: FILE:read FILE:write |
| Token Type: location | ||
| Defining Authority: system_manager | ||
| Value: *.USC.EDU |
The policy language we presented supports authorization models based on the closed world model, when all rights are implicitly denied. Authorizations are granted by an explicit listing of positive access rights.
The open world model, which is based on implicit granting of all rights, and listing of only negative authorizations can be represented in our model by including
| Token Type: access_identity_ANYBODY | ||
| Defining Authority: none | ||
| Value: none |
| Token Type: positive_access_rights | ||
| Defining Authority: local_manager | ||
| Value: * |
as the final entry in an EACL. This will grant everybody all rights regardless of authentication. Denial of rights is then specified using negative rights in entries earlier in the EACL.
Restrictions placed on positive access rights have the goal of restricting the granted rights. The meaning of restrictions on negative (denied) access rights is unclear. We intend to investigate this issue, however, for the time being, we require that:
1) A single EACL entry must not specify both positive and negative rights.
2) If an EACL entry specifies negative rights, it must not have any restrictions.
If one allows both negative and positive authorizations in individual or group entries, inconsistencies must be resolved according to different resolution rules. The design approach we adopted allows the ordered interpretation [10] of EACLs. An ordered evaluation approach is easier to implement, it allows only partial evaluation of EACL and resolves the authorization conflicts. Evaluation of ordered EACL starts from the first to the last in the list of EACL entries. The resolution of inconsistent authorization is based on ordering. The authorizations that already have been examined take precedence over new authorizations.
Other interpretations are possible, but we found that for many such policies, resolution of inconsistencies was either NP-Complete or undecidable.