Previous section.

Authorization (AZN) API
Copyright © 2000 The Open Group

Authorization API Usage Model

System Structure

aznAPI System Structure illustrates the structure of a system which uses the aznAPI.





Figure: aznAPI System Structure


Resource requests in a system using the aznAPI are mediated by Access Enforcement Functions (AEFs).

AEFs authenticate users (often using Authentication Services). They also authorize requests by passing Access Control Information (ACI) to the Authorization API (aznAPI). They fulfill authorized requests and reject unauthorized requests.

The aznAPI translates ACI received from AEFs into Access Control Decision Information (ADI). The aznAPI also uses Access Decision Functions (ADFs) to make access decisions.

ADFs use ADI and Access Policy Rules to decide whether an initiator's request to perform an operation on a target should be permitted or denied.

Supported Functions

aznAPI Functions lists the families of functions provided by the aznAPI and briefly describes what each family of functions does.

Interface Family Name Prefix Interface Family Supported Functions
azn_initialize, azn_shutdown Initialize aznAPI implementation

Clean up aznAPI implementation in preparation for shutdown

azn_creds Create, delete, modify, and combine credentials chains

Get information from credentials chains

Build PAC based on credentials chain

azn_id Build credentials chain based on authenticated identity produced by an authentication service
azn_decision Make an access decision
azn_entitlement Get access control policy information
azn_pac Build credentials chain based on PAC produced by an authorization service
azn_error Retrieve error information from status values returned by aznAPI functions
azn_authority Discover authentication, authorization, and credentials, label, and pac mechanisms supported by aznAPI implementation
azn_attrlist Create and delete attribute/value pair list

Write parameter data into attribute/value pair list

Read parameter data from attribute/value pair list

azn_release Release data allocated by aznAPI implementation

Table: aznAPI Functions

State Machine

aznAPI State Machine Summary summarizes the state machine of application (typically an AEF) which calls the aznAPI. AEFs should call aznAPI functions in the sequence indicated in aznAPI State Machine Summary. Note that the state machine in aznAPI State Machine Summary is only a summary overview and does not enumerate all the states the caller of an aznAPI implementation can take on. Note also that, since AEFs call authentication service functions through APIs other than aznAPI, not every state transition in aznAPI State Machine Summary is caused by an aznAPI function call.

aznAPI State Machine Transitions indicates the aznAPI function calls or other AEF operations which cause transitions from one state to another.






Figure: aznAPI State Machine Summary


Transition Operation Causing Transition
1 AEF gets request whose initiator has been authenticated by authentication service
2 AEF gets request; AEF authenticates initiator
3 AEF gets request whose initiator is described by a PAC produced by an aznAPI implementation
4 AEF calls azn_decision_access_allowed() to authorize request (credentials chain is built implicitly by authorization service using authentication service's identity obtained from environment)
5 AEF calls azn_id_get_creds() with null ID (authorization service uses authentication service's identity obtained from environment)
6 AEF calls azn_id_get_creds() with ID AEF generated when it authenticated initiator
7 AEF calls azn_pac_get_creds()
8 AEF calls azn_creds_combine() to add its credentials chain to that of the initiator
9 AEF calls azn_creds_modify() to change the attributes of the credentials chain
10 AEF calls azn_creds_modify() to change the attributes of the credentials chain
11 AEF calls azn_decision_access_allowed()
12 AEF calls azn_creds_get_pac()
13 AEF calls azn_creds_get_pac()
14 AEF calls azn_decision_access_allowed()

Table: aznAPI State Machine Transitions

The state machine in aznAPI State Machine Summary is divided into three phases:

  1. Credential Establishment
    During this phase, represented by the leftmost column of states after the start state, the AEF uses the aznAPI to establish credentials chain which the authorization service will use as the basis for later operations.

  2. Credential Modification
    During this phase, represented by the second column to the right of the start state, the AEF modifies the initiator's credentials chain, either by changing the attributes contained in it or by combining its own credentials chain with the initiator's.

  3. Credential Use
    During this phase, represented by the rightmost column, the AEF uses the credentials chain, either to make authorization decisions or to create PACs which it can pass to other AEFs.

Functions Not Included in State Diagram
aznAPI State Machine Summary Some functions of the aznAPI have been omitted from the summary state diagram shown in aznAPI State Machine Summary for purposes of simplicity. The omitted functions include:

Trust Model

Each component of a secure system needs to know which other components can be trusted, and what they can be trusted to do. This section describes the trust relationships among the components of a system which uses the aznAPI.

Relationship between Authentication and Authorization

The aznAPI separates authentication from authorization, as illustrated in Relationship between Authentication and Authorization.





Figure: Relationship between Authentication and Authorization


The initiator may use an authentication service to create an "Identity" which is received by an AEF along with the initiator's request to access a target.

The AEF calls the aznAPI to transform the initiator's identity into a credentials chain, which can be used to make access control decisions.

The AEF may, if it needs to pass the initiator's request on to another AEF for fulfillment, call the aznAPI to transform the credentials chain into a PAC, which represents the authorization service's view of the initiator (rather than the authentication service's view, which was represented by the Identity).

Another AEF receiving this PAC is able to transform it into a credentials chain, which can be used to make access control decisions.

In a system using the aznAPI, therefore:

It is therefore always possible to distinguish authentication data and authorization data, and the authorization service never uses one type of data where another is required. In particular, the authorization service never uses authentication data to make an access decision.

It is up to AEFs to make trust decisions about authentication data; an aznAPI implementation does not make trust or authenticity judgments about the identities passed to it by AEFs.


TCB Boundary

Trust Relationships in an aznAPI System indicates that the AEF, the aznAPI, the ADF, the PAC Service, the authentication service, and any authentication mechanisms used by the authentication service, are all inside the trusted computing base (TCB) of the system and thus need to be protected against unauthorized modification.





Figure: Trust Relationships in an aznAPI System


The components of the system have the following trust relationships:


Why not acquire a nicely bound hard copy?
Click here to return to the publication details or order a copy of this publication.

Contents Next section Index