Previous | Table of Contents | Next |
The SAS protocol combines common authorization (security attribute) functionality with client authentication functionality
and is intended to be used in conjunction with a transport-layer security mechanism, so that there may be as many as three
protocol layers of security functionality. This section describes the semantics of the compound security mechanisms that may
be realized using this interoperability architecture.
The three protocol layers build on top of each other. The transport layer is at the bottom. The client authentication functionality
of the SAS protocol provides a way to layer additional client authentication functionality above the transport layer. The
common authorization functionality provides a way to layer security attribute functionality above the authentication layers.
Any or all of the layers may be absent.
A target describes in its IORs the CSI compound security mechanisms it supports. Each mechanism defines a combination of layer-specific
security functionality
supported by the target, as defined in Section 24.5.1.5,
“TAG_CSI_SEC_MECH_LIST,? on page 24-38.
The mechanisms a client uses to interact with a target shall be compatible with the target’s capabilities and sufficient to
satisfy its requirements.
7.
As defined in “IETF RFC 2743? on page 24-58, “Generic Security Service Application
Program Interface Version 2, Update 1?, J. Linn, January 2000.
24.3.1.1 Context Validation
A target indicates its requirements for client authentication in its IORs. The layers at which a CSS authenticates to a TSS
shall satisfy the requirements established by the
target (see the description in Section 24.5.1, “Target Security Configuration,? on
page 24-32). When a CSS attempts to authenticate with a TSS using the client
authentication functionality of the SAS context layer protocol (by including a client_authentication_token in an EstablishContext
message), the authentication context established in the TSS will reflect the result of the service context authentication
(after having satisfied the target’s requirement for transport level authentication, if any).
If the service context authentication fails, the following shall happen:
• The request shall be rejected, whether or not authentication is required by the target.
• An exception containing a ContextError service context element shall be returned to the CSS. The ContextError service context element shall contain major and minor status codes indicating that client authentication failed.
If the request does not include a client_authentication_token, the client authentication identity is derived from the transport
layer.
When a request includes an identity token, the TSS shall determine if the identity established as the client authentication
identity is trusted to assert the identity represented in the identity token.
A TSS that does not support authorization-token-based delegation (see Section 24.6,
“Conformance Levels,? on page 24-45) shall evaluate trust by applying the client
authentication identity and the asserted identity to trust rules stored at the target. We call the evaluation of trust based
on rules of the target a backward trust evaluation.
When a TSS that supports authorization-token-based delegation receives a request that includes both an identity token and
an authorization token with embedded proxy attributes, the TSS shall evaluate trust by determining whether the proxy attributes
were established (that is, signed) by a privilege authority acceptable to the target and whether the client authentication
identity is included in the identities named in the proxy attributes. We call the evaluation of trust based on rules provided
by the caller a forward trust evaluation. A TSS shall not accept requests that failed a forward trust evaluation based on
a backward trust evaluation.
A TSS shall determine that a trusted identity established in the authentication layer(s) is trusted to assert exactly the
same identity (in terms of identifier value and identification mechanism) in an identity token.
In either case of forward or backward trust evaluation, if trust is established, the context is considered correctly formed.
Otherwise, the TSS shall reject the request by returning an exception containing a ContextError service context element. The
ContextError element shall contain major and minor status codes indicating that the evidence was invalid.
If a request includes an authorization token but does not include an identity token, the TSS shall ensure that the access
identity named in the authorization token is the same as the client authentication identity. If the request includes an identity
token, the TSS shall ensure that the access identity is the same as the identity in the identity token. A TSS that supports
authorization-token-based privilege attributes shall reject any request that does not satisfy this constraint and return an
exception containing a ContextError service context element. The ContextError element shall contain major and minor status
codes indicating that the evidence was invalid.
When a request includes an authorization token, it is the responsibility of the TSS to determine if the target trusts the
authorities that signed the privileges in the token. A TSS that supports authorization-token-based privilege attributes shall
reject any request with an authorization token that contains privilege information signed by an authority that is not trusted
by the target. In this case, the TSS shall return an exception containing a ContextError service context element. The ContextError
element shall contain major and minor status codes indicating that the evidence was invalid.
24.3.1.2 Legend for Request Principal Interpretations
This section serves as a key to the invocation scenarios represented in Table 24-3 on
page 24-19, Table 24-4 on page 24-20, and Table 24-5 on page 24-21. The three tables
describe the interpretation of security context information arriving at a target object from a calling object, object 2, that
may have been called by another object, object 1. The authentication identity of object 2, as seen by the target object, may
have been established in the transport layer, or the SAS context layer, or both. If the authentication identity was established
at the transport layer it is referred to as P2A. If the authentication identity was established at the SAS context layer it
is referred to as P2B. The authentication identity seen by object 2 when it is called by another object (that is, object 1)
is referred to as P1, the authentication identity of object 1. No distinction is made between the transport and SAS layer
authentication identities of object 1 as seen by object 2. Object 1 may also call object 2 anonymously.
P1 is also used to represent a non-anonymous identity that may be asserted by object 2 when it calls the target object. When
object 2 calls the target object, it may include an asserted identity in the form of an identity token in its SAS layer context.
The asserted identity may be the anonymous identity or, a non-anonymous identity (represented by P1). When object 2 asserts
an identity to the target object, it may (or may not) establish proof of its own identity by authenticating at either or both
of the transport (P2A), or SAS (P2B) layers. When the target object receives a request made with an asserted identity, the
target object will determine if it trusts the client authentication identity (that of object 2, or P2) acting as proxy for
the asserted identity (that of object 1, or P1).
When object 2 asserts a non-anonymous identity to the target object, it may include with its request a SAS layer authorization
token containing PACs. Each PAC may include an attribute that assigns proxy to a collection of identities that are endorsed
by the authority that created the PAC to assert the identity to which the privileges in the PAC apply. When the target object
receives a request made with an asserted identity and an authorization token containing proxy rules, the target object will
use the proxy rules to determine if it may trust the client authentication identity (P2A or P2B) as proxy for the asserted
identity(P1).
SAS: P2B
Transport: P2A
Figure 24-2 Invocation Scenarios
24.3.1.3 Anonymous Identity Assertion
The anonymous identity is used to represent an unauthenticated entity. To assert an anonymous caller identity, a CSS (perhaps
acting as an intermediate) shall include a SAS context element containing an EstablishContext message with an identity_token
containing the anonymous IdentityTokenType in its request.
24.3.1.4 Presumed Trust
Presumed trust is a special case of the evaluation of identity assertions by a TSS. In presumed trust, a TSS accepts identity
assertions based on the fact of their occurrence and without consideration of the authentication identity of the asserting
entity. The presumption is that communications are constrained such that only trusted entities are capable of asserting an
identity to the TSS.
24.3.1.5 Failed Trust Evaluations
Table 24-3 shows the circumstances under which the interpretation of caller credentials
by a TSS results in a failed trust evaluation. None of these circumstances correspond to presumed trust, where trust evaluations
are not performed (and therefore cannot fail).
Table 24-3 Conditions under which Trust Evaluation Fails
Transport Client Principal |
SAS Client Authentication Principal |
SAS Identity Token Identity |
Does Target Trust P2, or Is P2 Named as Proxy in Authorization Elements? |
||
None | None | P1 | Not Applicable | ||
None | P2B | P1 | No (with respect to P2B) | ||
P2A | None | P1 | No (with respect to P2A) | ||
P2A | P2B | P1 | No (with respect to P2B) |
A failed trust evaluation shall result in the request being rejected with an indication that client authentication failed.
July 2002 CORBA, v3.0: Security Attribute Service Protocol
24.3.1.6 Request Principal Interpretations
The entries in Table 24-4 describe the interpretation of client credentials by a TSS after
an incoming call has satisfied the target’s security requirements and has been validated by the TSS.
Table 24-4 TSS Interpretation of Client Credentials After Validation
Transport Client Principal |
SAS Client Authentication Principal |
SAS Identity Token Identity |
Client Principal is Trusted |
Invocation Principal |
Scenario |
None | None | Absent | Not applicable | Anonymous | Unauthenticated |
None | P2B | Absent | Not applicable | P2 | Client authentication |
P2A | None | Absent | Not applicable | P2 | Client authentication |
P2A | P2B (by rule 11) | Absent | Not applicable | P2B | Client authentication |
None | None | P1 | Yes if rule 22 | P1 | identity assertion |
None | P2B | P1 | Yes if rule 2 or rule 33 | P1 | identity assertion |
P2A | None | P1 | Yes if rule 2 or rule 3 | P1 | identity assertion |
P2A | P2B (by rule 1) | P1 | Yes if rule 2 or rule 3 | P1 | identity assertion |
None | None | Anonymous | Yes if rule 44 | Anonymous | assertion of anonymous |
None | P2B | Anonymous | Yes if rule 4 | Anonymous | assertion of anonymous |
P2A | None | Anonymous | Yes if rule 4 | Anonymous | assertion of anonymous |
P2A | P2B (by rule 1) | Anonymous | Yes if rule 4 | Anonymous | assertion of anonymous |
none | No SAS Message | Not Applicable | Anonymous | Unauthenticated | |
P2 | No SAS Message | Not Applicable | P2 | Client authentication |
1. Rule 1: TSS trusts P2A to use authenticator for P2B is implied by P2B having been authenticated.
2. Rule 2: TSS presumes trust in transport to accept None, P2A, or P2B speaking for P1.
3. Rule 3: TSS trusts P2A, or P2B to speak for P1.
4. Rule 4: TSS trusts None, P2A, or P2B to speak for Anonymous. A TSS shall support the configuration of rule 4, such that Anonymous identity assertions are accepted independent of authentication of the asserter.
The entries in Table 24-5 describe additional TSS interpretation rules to support
delegation. These rules have been separated from those in Table 24-4 on page 24-20,
because they describe functionality required of implementations that conform to a
higher level of secure interoperability as defined in Section 24.6.3, “Conformance
Level 2,? on page 24-47. The entries in Table 24-5 correspond to invocations that carry
an identity token and an authorization token with embedded delegation token (that is, a proxy endorsement attribute) in an
EstablishContext service context element. Invocations
that do not carry all of these tokens are represented in Table 24-4.
An authorization token may contain authorization elements that contain proxy
statements, which endorse principals to proxy for other entities. Table 24-5 describes
delegation scenarios in which endorsements from the issuer of the authorization element authorize the authenticated identity,
which is P2A or P2B, to proxy for the asserted identity. In this table, the column “Proxies Named in Authorization Element?
defines the identities who are endorsed by the authorization element to proxy for P1, the asserted identity and the subject
of the authorization element. The value “Any? indicates that the authorization element contains a blanket endorsement, such
that as far as its issuer is concerned, any identity may proxy for P1. The outcomes described
in Table 24-5 assume that the TSS trusts the issuer of the authorization element to
endorse principals to proxy for others.
Table 24-5 Additional TSS Rules to Support Delegation
Transport Client Principal |
SAS Client Authentication Principal |
SAS Identity Token Identity |
Proxies Named in Authorization Element |
Invocation Principal |
Scenario |
None | P2B | P1 | Any | P1 | Delegation |
P2A | None | P1 | Any | P1 | Delegation |
P2A | P2B | P1 | Any | P1 | Delegation |
None | P2B | P1 | Restricted to set including P2B | P1 | Restricted delegation |
P2A | None | P1 | Restricted to set including P2A | P1 | Restricted delegation |
P2A | P2B | P1 | Restricted to set including P2B | P1 | Restricted delegation |