This document describes: 1. Policy language which allows one to represent existing access control models (e.g. ACL, capability) in a uniform and consistent manner. Authorization restrictions allow one to define what operations are allowed, and under what conditions (e.g., user identity, time of day, day of week) particular rules apply. 2. Globus implementation: functions calling the Generic Authorization and Access-control API (GAA API) routines. A common access control API facilitates the integration of authentication and authorization with applications. This API allows applications to request the authorization policy information for particular resource and to evaluate this policy against credentials carried in the security context for the current connections. Applications invoke the GAA API functions to determine if a requested operation or set of operations was authorized or if additional checks are necessary. 0. Glossary OBJECT (RESOURCE) entity that has to be protected e.g. hosts, files. SUBJECT entity that can initiate requests to an object e.g. individual users, hosts, applications and groups. PRINCIPAL identity associated with a subject as a result of some unspecified authentication protocol. It can refer to a person, group, host, and application. Several principals can be associated with the same subject. SECURITY POLICY the set of rules that govern access to objects ACCESS RIGHT (OPERATION, PERMISSION) a particular type of access to a protected object e.g. read, write, and execute RESTRICTION (CONDITION) a specific policy allowing an operation to be performed on an object This policy can have two meanings: 1) descriptive An operation is allowed if certain condition is satisfied. For instance, a policy may require concurrence of two principals to perform some operation. If participation of both principals can be proved then this policy is satisfied. 2) prescriptive An operation will be allowed if certain restrictive policy is enforced. For example, a process will be authorized to run on a host if the memory usage limits that a process can occupy in main memory satisfies certain constraints. Continuous evaluation of restriction is required. DELEGATION is the ability of a principal to give to another principal limited authority to act on its behalf. CREDENTIAL a statement of identity, group membership and non-membership, privilege attribute and transfer of privilege encoded in certificates. CERTIFICATE CHAIN Certificates can comprise a chain, where each certificate (except the last one) is followed by a certificate of its issuer. Reliable authentication of public key must be based on complete chain of certificates which starts at an end-entity (e.g. user) certificate, includes zero or more CA certificates and ends at a self-signed root certificate. 1. Policy Language One may think about the security policy associated with a protected resource as a set of operations which a defined set of principals is allowed to perform on the target resource, and optional constraints placed on the granted operations. For example, a system administrator can define the following security policy to govern access to a printer: "Joe Smith and members of Department1 are allowed to print documents Monday through Friday, from 9:00AM to 6:00PM". This policy can be described by an ACL mechanism, where for each resource, a list of valid entities is granted a set of access rights. The same policy can be implemented using a capability mechanism. However, traditional ACL and capability abstractions should be extended to allow conditional restrictions on access rights. Therefore, in implementing a policy, it should be possible to define: 1) access identity 2) grantor identity 3) a set of access rights 4) a set of conditions The policy language represents a sequence of tokens. Each token consists of: Token Type Defines the type of the token. Tokens of the same type have the same authorization semantics. Defining Authority Indicates the authority responsible for defining the value within the token type. Value The value of the token. Its syntax is determined by the token type. The name space for the value is defined by the Defining Authority field. 1.1 Specification of Access Identity The access identity represents an identity to be used for access control purposes. 1) USER identifies a person, e.g. authenticated user name. 2) HOST identifies a subject as a machine from which request to access the object was originated, e.g., an IP address or host DNS name or host public key. 3) APPLICATION identifies a certain program that has its own associated identity (principal),e.g., a checksum or certified name. This can be useful to grant access to a certain application, e.g. payment program, that is trusted to be written correctly and perform only its intended purpose. 4) CA identifies a Certification Authority responsible for issuing a certificate. 5) GROUP identifies a group of subjects. The kind of subjects (individual user, host or application) composing the group is opaque to the authorization mechanism. 6) ANYBODY represents any subject regardless of authentication. This may be useful for setting the default policies. The principal type can be useful in determining which additional credentials are needed (see section 1.7). Principals can be aggregated into a single entry when the same set of access rights and conditions applies to all of them. The framework supports multiple existing principal naming methods. Different administrative domains might use different authentication mechanisms, each having a particular syntax for specification of principals. Therefore, Defining Authority for access identity indicates the underlying authentication mechanism used to provide the principal identity. Value represents the particular principal identity. 1.2 Specification of Grantor Identity The grantor identity represents an identity used to specify the grantor of a capability or a delegated credential. Its structure is similar to the one of the access identity described in the previous subsection. 1.3 Specification of Access Rights It must be possible to specify which principals or groups of principals are authorized for specific operations, as well as who is explicitly denied authorizations, therefore we define positive and negative access rights. All operations defined on the object are grouped by type of access to the object they represent, and named using a tag. 1.4 Specification of Conditions Conditions specify the type-specific policies under which an operation can be performed on an object. A condition is interpreted according to its type. These are several of the implemented generic conditions: a. time Time periods for which access is granted. Token Type: cond_time Defining Authority: hr_scale_24 Value: 16:20:13-22:30:25 Token Type: cond_day Defining Authority: globus Value: Monday-Friday b. trust constraints Public key authentication requires consideration of the trustworthness of the certifying authorities for the purpose of public key certification. Authentication can not be based on the public key alone, anybody can issue a valid certificate. A policy must be specified to validate the legitimacy of the received certificate chain and the authenticity of the specified keys. The policy may express the following trust constraints: 1) Specify trustworthness of CA to sign certificates for limited set of users. 2) Constraints placed in the certificates by CA when issuing a certificate. They are represented as a list of certificate extensions and marked as critical/non-critical. For example, the extension may contain policy specifying that no further delegation of CA authority is allowed. 3) Restrictions on certification path: a) Permitted and denied subtrees of CA authorities. b) Limit the length of certificate chains (depth of the subtree). 4) Restrictions imposed on cryptographic attributes: - accepted signature scheme (e.g. DSA/SHA, RSA/MD2) - minimum public key length (768, 1024 bits) Globus Security Infrastructure is implemented on top of the GSS-API which allows the integration of different underlying security mechanisms. Currently, GSI implementation uses SSL authentication protocol with X.509 certificates. Currently only restriction 1) is implemented. c. strength of authentication Specifies the authentication mechanism or set of suitable mechanisms, for authentication. The framework supports various strengths of user authentication mechanisms. An EACL may have entries associated with different principals identifying the same subject using different authentication methods. A subject 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. d. location (not fully implemented) Location of the principal. Authorization is granted to the principals residing in specific hosts or domains. Other useful conditions which have not yet been implemented: e. connection e.1. security of the connection 1) required confidentiality message protection This condition specifies a mechanism, or a set of mechanisms to be used in confidentiality message protection. 2) required integrity message protection This condition specifies a mechanism, or a set of mechanisms to be used in integrity message protection. e.2. bandwidth e.3. particular network (SAN vs. LAN for a cluster) e.4. dialup f) privilege constraints In general, a principal may belong to more than one group. By default, principal operates with the union of privileges of all groups to which it belongs, as well as all of his individual privileges. In assigning privileges, one can choose to: 1) have the subject operate with the privilege of only one group at a time. This can be used to reduce privileges as a protection against accidents. E.g. a person is a member of two groups: PROGRAMMERS and SYSTEM_MANAGERS. The person may act with the privileges of the group PROGRAMMERS most of the time, and enable privileges of the SYSTEM_MANAGERS group only on occasion. 2) have the subject operate with privileges of several specified groups at a time. This condition class allows one to express "group A and group B" 3) endorsement Concurrence of several principals to perform some operation. g) payment Specifies currency and amount that must be paid prior access to an object will be granted. h) quota Specifies a currency and a limit. It limits the quantity of a resource that can be consumed or obtained. i) attributes of subjects This class of conditions defines a set of attributes that must be possessed by subjects in order to get access to the object, e.g. user's age. 1.5. Extended Access Control Lists (EACLs) Extended Access Control Lists (EACLs) extend the conventional ACL concept by allowing specification of conditional authorization policies, implemented as conditions 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. # Example of EACL # # This is the configuration file describing the policy stating that # anyone authenticated by Kerberos.V5 has read and write access to the # targeted resource and anyone authenticated by X509 certificate # has read access to the object on Monday through Friday. # # Format: #---------------------------------------------------------------------------- # token type | def.authority | value #-----------------|---------------|------------------------------------------ # EACL entry #1 | access_id_ANYBODY pos_rights MicrosoftWord FILE:read,write cond_sec_mech local_manager kerberos.v5 # EACL entry #2 | access_id_ANYBODY pos_rights MicrosoftWord FILE:read cond_sec_mech local_manager X509 cond_day local_manager Monday-Friday # end of EACL 1.6 Backus-Naur Form Square brackets, [ ], denote optional items and curly brackets, {}, surround items that can repeat zero or more times. A vertical line, |, separates alternatives. Items inside double quotes are the terminal symbols. An EACL is specified according to the following format: eacl ::= {eacl_entry} eacl_entry ::= access_id {access_identity} pos_rights {restriction} {pos_rights {restriction}} | access_id {access_identity} neg_rights access_identity ::= access_identity_type def_authority value access_identity_type ::= "access_id_HOST" | "access_id_USER" | "access_id_GROUP" | "access_id_CA" | "access_id_APPLICATION" | "access_id_ANYBODY" A capability is defined according to the following format: capability ::= grantor_id pos_rights {condition} {pos_rights {condition}} grantor_id ::= grantor_id_type def_authority value grantor_id_type ::= "grantor_id_HOST" | "grantor_id_USER" | "grantor_id_GROUP" | "grantor_id_CA" | "grantor_id_APPLICATION" | "grantor_id_ANYBODY" pos_rights ::= "pos_rights" def_authority value {"pos_rights" def_authority value} neg_rights ::= "neg_rights" def_authority value {"neg_rights" def_authority value} restriction ::= condition_type def_authority value condition_type ::= alphanumeric_string def_authority ::= alphanumeric_string value ::= alphanumeric_string 1.7 EACL evaluation The policy language supports 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_id_ANYBODY Defining Authority: none Value: none Token Type: pos_rights Defining Authority: * 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 conditions 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 conditions. 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 of EACLs. 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. In general, when an EACL grants requested operation and no additional credentials are required, the GAA API will look for credentials that can cause denial. A principal may chose to withhold credentials that it believes may result in a denial. There may be interactions when independent credentials are used, i.e., one set of credentials causes denial, but the other causes accept. Administrator has to deal with these issues by carefully setting policies in an EACL. It may be appropriate to specify more restricted set of rights and require grant credentials to be presented. A condition may specify whether grant or denial credentials take precedence. Conflicts may arise when more then one entry applies. For example, one matching entry corresponds to a principal specifying individual subject (user, host, ca or application), and the second entry matching a certain group name. In this case, one would expect the entry for the individual subject to be placed before the entry for the group, on the assumption that the policy expressed by the individual subject entry is an exception to the policy expressed by the group entry. When several EACL entries with different conditions apply, the access is based on the conditions in the first matching entry found. An ordered evaluation approach is easier to implement as it allows only partial evaluation of EACL and resolves the authorization conflicts. The problem with this approach is that it requires total ordering among authorization. It requires careful writing of EACL by the security administrator and is error prone. 1.8 Credential evaluation Credentials are translated to the GAA API internal format and placed into the GAA API security context. When evaluating an EACL, the necessary credentials are looked for in the security context. EACL entries containing principals that do not match the current subject identity but grant the requested operation and the identities that are associated with the subject, stored in the security context, e.g. group memberships and delegated credentials, are taken into account when evaluating an EACL. Assume that file doc.txt has the following EACL: # Example of EACL which guard access to the file doc.txt # # Format: #---------------------------------------------------------------------------- # token type | def.authority | value #------------------|---------------|----------------------------------------- # EACL entry #1 | access_id_USER X509 "/C=us/O=alliance/CN=Tom" pos_rights local_manager FILE:read # EACL entry #2 | access_id_GROUP kerberos.V5 admin@ORG.EDU pos_rights local_manager FILE:read,write # EACL entry #3 | access_id_USER kerberos.V5 joe@ORG.EDU pos_rights local_manager FILE:write # end of EACL Assume the following credentials are stored in the security context associated with the user Tom: identity credential: ------------------- access_id_USER "/C=us/O=alliance/CN=Tom" condition: cond_time hour_scale_24 06:00;00-19:30:00 group membership credential: access_id_GROUP kerberosV5 admin@ORG.EDU condition: privilege local_manager restricted delegation credential: ---------------------- grantor: grantor_id_USER kerberosV5 joe@ORG.EDU grantee: access_id_USER kerberosV5 tom@ORG.EDU objects: doc.txt rights: pos_rights local_manager FILE:write condition: location local_manager *.org.edu Let's consider a request from a user Tom who is connecting from the ORG.EDU domain to write to the file doc.txt at 5pm. In evaluating the EACL, the first entry does not grant the requested operation, the second entry grants it. The evaluation function will check the security context for the group admin membership credential. The proper credential is found, however, there is a condition privilege:restricted. It means that Tom can use this privilege only if logged in as an administrator. Evaluation continues. The third entry grants the requested operation. The evaluation function will look for delegation credential for tom@ORG.EDU issued by joe@ORG.EDU. The appropriate delegation credential is found and it grants the requested operation. The condition on location *org.edu is satisfied, so the requested access will be granted. 2. Globus implementation Currently the GAA API is used by the GSI during the authentication stage for verifying X.509 certificate validity. # ca-signing-policy.conf # # This is the configuration file describing the policy for what CAs are # allowed to sign whose certificates. # # This file is parsed from start to finish with a given CA and subject # name. # subject names may include the following wildcard characters: # * Matches any number of characters. # ? Matches any single character. # # CA names must be specified (no wildcards). Names containing whitespaces # must be included in single quotes, e.g. 'Certification Authority'. # Names must not contain new line symbols. # The value of condition attribute is represented as a set of regular # expressions. Each regular expression must be included in double quotes. # # This policy file dictates the following policy: # -The Globus CA can sign certificates for the Globus or the Alliance # -The Alliance CA can sign certificates for the Alliance (note that # this may not be the real DN for the Alliance CA). # # Format: #------------------------------------------------------------------------ # token type | def.authority | value #--------------|---------------|----------------------------------------- # ACL entry #1 | # Globus CA rights access_id_CA X509 '/C=US/O=Globus/CN=Globus Certification Authority' pos_rights globus CA:sign cond_subjects globus '"/C=us/O=Globus/*" "/C=US/O=Globus/*"' # Alliance CA rights access_id_CA X509 '/C=US/O=National Computational Science Alliance/CN=Globus Certification Authority' pos_rights globus CA:sign cond_subjects globus '"/C=us/O=National Computational Science Alliance/*"' # End of ca-signing-policy.conf The EACL is used by the GAA API routines from the gaa library to check the validity of particular entity (signer) to sign certificates for another entity (subject). grid-check-ca-policy-file obtains policy file (EACL) from the default location, parses it, builds the GAA internal policy structure and prints it out. Reports encountered parse errors. grid-check-ca-sig obtains policy file (EACL) from the default location, parses it, builds the GAA internal policy structure and checks if the specified signer is allowed to sign certificates for specified subject. grid-inquire-policy-info obtains policy file (EACL) from the default location, parses it, builds the GAA internal policy structure, finds EACL entry corresponding to the signer and returns a list of authorized rights and corresponding conditions, if any. Function: proxy_verify_callback() (from gssapi_ssleay/sslutils.c) calls the GAA routines to check that proxy certificates are only signed by the correct user.