OSF DCE Application Development Guide--Core Components

The Extended Privilege Attribute API
26.2.3 Optional and Required Restrictions
When a principal calls sec_login_become_initiator( ) to enable delegation, or
sec_login_become_delegate() or sec_login_become_impersonator( ) to become an
intermediary, the principal can specify optional and required restrictions. Optional and
required restrictions are provided for use by applications that have specific authorization
requirements. These restrictions, which are defined by the application, can be set by
initiators or intermediaries, and are interpreted and enforced by application target
servers. Servers can ignore optional restrictions that they cannot interpret, but they must
reject requests associated with a required restriction that they cannot interpret. Both
optional and required restrictions are supplied as values of type sec_id_opt_req_t. They
are inserted in an EPAC by the privilege server and evaluated by the target server
application.
26.2.4 Compatibility Between Version 1.1 and Pre-Version 1.1 Servers
and Clients
Prior to DCE Version 1.1, a principal’s privilege attributes were stored in a privilege
attribute certificate (PAC). At Version 1.1, the PAC was renamed to EPAC and extended
to include the following:
• Target, delegate, optional, and required restrictions.
• Extended registry attributes (ERAs), as described in Chapter 28.
Additionally, authorization credentials can now consist of multiple EPACs, as in
delegation chains, instead of a single PAC.
When a pre-Version 1.1 client interacts with a Version 1.1 server or vice versa, the
Version 1.1 server requires an EPAC and the pre-Version 1.1 server requires a PAC.
For Version 1.1 servers, the security runtime automatically converts the PAC supplied by
a pre-Version 1.1 client to an EPAC. For pre-Version 1.1 servers, the security runtime
automatically extracts PAC data from the credentials supplied by the Version 1.1 client.
However, because an EPAC for a delegation chain contains the privilege attributes of
multiple principals and a PAC contains only one set of privilege attributes, the principals
engaged in delegation must specify how to handle this issue of multiple versus single
identities.
When a principal initiates delegation or becomes an intermediary in a delegation chain,
that principal can specify whether to use the privilege attributes of the chain initiator or
the last intermediary in the chain to construct the PAC required by a pre-Version 1.1
server. This compatibility decision is specified as a value of type
sec_id_compatibility_mode_t, which is set to one of the following three values:
• sec_id_compat_mode_none
Compatibility mode is off. The security runtime supplies the application server with
an unauthenticated PAC.
124245 Tandem Computers Incorporated 26−7