Architectural Overview

This authorization API defines a programmatic interface through which system components that need to control access to resources can request an access control decision from the system's access control service.

The ISO 10181-3 access control framework supports access control in both standalone and networked systems. When this document refers to the system, it means "the computer or collection of networked computers whose resources are protected by the access control service which is invoked using the authorization API."

ISO 10181-3 Access Control Framework

The framework defines four roles for components participating in an access request:

• Initiators

• Targets

• Access Control Enforcement Functions (AEFs)

• Access Control Decision Functions (ADFs)

Initiators submit access requests. An access request specifies an operation to be performed on a Target.

Access Control Enforcement Functions (AEFs) mediate access requests. AEFs submit decision requests to Access Control Decision Functions (ADFs). A decision request asks whether a particular access request should be granted or denied.

ADFs decide whether access requests should be granted or denied.

Access Control Service Components

Access Control Decision Functions

Inputs to an Access Decision Function (ADF) shows the information an ADF uses to make an access control decision.

Access Control Enforcement Functions

The authorization API (referred to hereafter as aznAPI) is the medium through which AEFs call on ADFs to obtain access control decisions. AEFs use the aznAPI to present Access Control Information (ACI) to ADFs. As AEFs Use the Authorization API to Call ADFs illustrates, the implementation of the aznAPI is responsible for deriving ADI from the ACI provided by an AEF and presenting the ADI to an ADF. The ADF then uses this ADI, together with access control policy rules and with context ADI it derives from its environment, to make an access decision.

Access Control Information

• Determining which of the ACI presented by the AEF is relevant to the access control decision the AEF requested

• Transforming the ACI presented by the AEF into ADI in a form which can be used by the ADF

• Presenting the resulting ADI to the ADF

There are several kinds of Access Control Information. The main kinds describe authorization-relevant properties of the initiator, the target, the access request, and the context within which the request was made.

Initiator Information

• Initiator ACI is the initiator information which is available to AEFs.

• Initiator ADI is the initiator information which results from the aznAPI's transformation of initiator ACI and is made available to ADFs.

Initiator ACI

The aznAPI may also accept a capability as an Identity. A capability is a direct assertion by an authentication service of the capability holder's authorization to perform specific operations on specific targets. As A Capability shows, a capability is asserted (using a signature, for example) by some authority. A capability does not necessarily name its initiator; whoever possesses a capability can use it. In A Capability, this is indicated by the dotted line around the initiator identity. Finally, a capability contains a list of policy entries. Each entry names a target object and defines a rule which describes the operations which it allows the initiator to perform.

Note that aznAPI implementations are not required to support any particular identity format, and are specifically not required to support capabilities.

Initiator ADI

Although the aznAPI does not allow callers to access credentials chains directly, it does provide functions through which attribute information may be retrieved from credentials chains.

Transforming Initiator ACI into a Credential shows how the aznAPI transforms Initiator ACI into credentials chains, and returns a credential handle to the caller. Note that the aznAPI can be used in systems which "push" privilege attributes from clients to AEFs, or in systems which require AEFs to "pull" privilege attributes from a repository or service. In push-model environments, the Initiator ACI will contain the privilege attributes pushed by the client, and will be translated into an internally usable form by the aznAPI implementation. In pull-model environments, the Initiator ACI typically contains only a single privilege attribute (for example, the authenticated name of the Initiator), and the aznAPI implementation pulls the rest of the Initiator's privilege attributes from the appropriate repository or structure during construction of the Initiator's credentials chain.

Target Information

• Target ACI is the target information which is available to AEFs.

• Target ADI is the target information which results from the aznAPI's transformation of target ACI.

Target ACI

Labels are an exception to this rule. The aznAPI has been designed to support access control decisions based on ADI contained in security labels. In some label-based authorization systems, however, the authorization service may not know how label information is encoded into the target, or how it is stored as metadata associated with the target. In these cases, the AEF needs to retrieve the target's labels and pass them to the aznAPI as target ACI. The aznAPI also supports implementations which can handle several different types of labels. Implementations which support multiple label types may require their callers to specify a labeling scheme ID identifying which type of label is being used in a particular call.

Target ADI

Some callers of the aznAPI may want to use authorization policy data for purposes other than making access control decisions. For this reason, the aznAPI supports externalization of ADI data into data structures called entitlements. Entitlements are discussed in more detail in Externalizing ADI.

Request Information

• Request ACI is the request information which is available to AEFs.

• Request ADI is the request information which results from the aznAPI's transformation of request ACI.

Request ACI

Request ADI

Context Information

There are two sources of context ADI:

• The first source is the context information which results from the aznAPI's transformation of context ACI.

• The second source is context information which was not provided as ACI but which is directly accessible to the authorization service.

Context ACI

• Time:
  The time at which the request occurred.

• Location:
  The location (source address) from which the request was initiated.

• Route:
  The security characteristics of the connection over which the request was transmitted from the initiator to the AEF.

• Quality of Authentication:
  The quality of authentication used to establish the initiator's identity.

In addition, the aznAPI allows AEFs to pass application-specific or authorization-service-specific context information, not limited to the above types, to authorization services using an opaquely-typed parameter. Use of this functionality will result in applications which cannot portably use authorization services which do not support the particular context information format passed through the opaque parameter.

Context ADI

Retained Information

Information retained by the authorization service for this purpose is ADI, and is never exposed to applications by the aznAPI. Therefore, the format of retained ADI is not defined or constrained by the aznAPI specification (retained ADI might in some circumstances be of interest to applications, but exposing retained ADI is not supported by this version of aznAPI).

Access Control Policy Information

Externalizing ADI

PACs

Externalization of initiator ADI allows the authorization service to assert its view of the security-relevant characteristics of the initiator, as distinct from the authentication service's view of the same initiator's security-relevant characteristics.

An authorization service could (but is not required to) use this functionality to generate signed attribute certificates which other services could rely on as sources of authorization data.

Because this specification defines only an opaque PAC structure, PACs produced by one authorization service are not guaranteed to be usable by another authorization service. However, a standard PAC structure could be defined in a future specification as the basis for interoperable assertion of initiators' authorization attributes by authorization services.

Note:

It is important to note that Signed PACs can be used as building blocks when constructing delegation protocols. The aznAPI does not, however, provide a delegation service. A delegation protocol must allow entities which wish to become delegates for requests received from an initiator to pass the following to a target:

1. The delegated request

2. A trustworthy indication that the request originally received from the initiator was authenticated

3. A trustworthy representation that the delegate is authorized to forward the request to the target on the initiator's behalf

4. A trustworthy representation of the initiator's and the delegate's credential information

Although the authorization service may sign PACs to form trustworthy representations of initiators' and delegates' credential information, and may even include identity information (such as a certificate issuer identity and identity certificate serial number) in a signed PAC to establish a link to the authentication data of the initiator, it does not bind PACs to requests (cryptographically or in any other way). AEFs which wish to impersonate or otherwise serve as delegates for initiators must use a separate cryptographic facility or delegation service to bind the PACs generated using the aznAPI to delegated request messages.

Note:

The term delegation is used here in the sense in which the DCE and SESAME systems use the term. Delegation is thus the security function through which an intermediary issues a request for access to a protected resource on behalf of an initiator from which it has itself received an access request. Other documents, notably X.509, use the term delegation with a different sense.

Entitlements

Externalization of access control policy information allows applications to customize the behavior of the system based on authorization policy. For example, it allows applications to modify system menus to display only operations which an initiator is permitted to access, rather than displaying all system operations and responding to the initiator's attempts to perform prohibited operations with an access denied message. Entitlement information could also be used by applications which want to make their own access decisions rather than relying on the ADF implemented by the authorization service.

The aznAPI defines a portable format for entitlement data that every authorization service can support - a list of the operations a particular initiator may (or may not) perform on a particular target. Portable Entitlements shows this format. Note that the dotted line around the subject data indicates that the initiator information is implicit; it is not returned by the aznAPI as part of the entitlement data.

The portable entitlement data representation is guaranteed to be supportable by all authorization service implementations, but it is not very efficient. Some authorization services may be able to express an initiator's authorizations to many operations on many targets using a single rule, or using a wildcarded expression. They may even be able to describe many initiators' authorizations in a single rule or expression. However, different authorization services use different rule formats, and there is no single rule format which can express all authorization services' rules efficiently. For this reason, the aznAPI allows authorization services to return non-portable entitlement information through an opaquely-typed parameter. As Non-Portable Entitlements illustrates, non-portable entitlement data may be in any rule format.

Use of non-portable entitlements requires the application calling the aznAPI to understand the authorization service's rule format, and prevents the application calling the aznAPI from using other authorization services with different rule formats.