24.2.2 SAS context_data Message Body Types

   Four message types comprise the security attribute service context management protocol. Each security attribute service context element shall contain a message body that carries one of the following message body types:

   • EstablishContext

   Sent by a client security service (CSS) to establish a security attribute service

   context.

   • ContextError

   Sent by a target security service (TSS) to indicate errors that were encountered in

   context creation, in the message protocol, or in use of a context.

   • CompleteEstablishContext

   Sent by a target security service (TSS) to indicate the outcome of a successful

   request to establish a security attribute service context.

   • MessageInContext

   Sent by a client security service (CSS) to associate request messages with an existing stateful security attribute service context. This message may also be used to indicate that the context should be discarded after processing the request.

   Stateful contexts, also known as reusable contexts, endure until they are discarded, and can be referenced for use with subsequent requests.

   A client security service (CSS) is the security service associated with the ORB that is used by the client to invoke the target object. A target security service (TSS) is the security service associated with the ORB that hosts the target object.

   24.2.2.1 EstablishContext Message Format

   An EstablishContext message is sent by a CSS to establish a SAS context with a TSS. The SAS context and the context identifier allocated by the CSS to refer to it are scoped to the transport layer connection or association over which the CSS and TSS are communicating. When an association is dismantled, all SAS contexts scoped to the connection shall be invalidated and may be discarded. The EstablishContext message contains the following fields:

   • client_context_id

   The CSS allocated identifier for the security attribute service context. A stateless CSS shall set the client_context_id to 0, indicating to the TSS that it is stateless. A stateful CSS may allocate a nonzero client_context_id. See Section 24.3.2.2, “Stateful/Reusable Contexts,? on page 24-22 for a definition of the rules governing the use and allocation of context identifiers.

   • authorization_token

   May be used by a CSS to “push? privilege information to a TSS. A CSS may use this token to send proxy privileges to a TSS as a means to enable the target to issue calls as the client.

   • identity_token

   Carries a representation of the invocation identity for the call (that is, the identity under which the call is to be authorized). The identity_token carries a representation of the invocation identity in one of the following forms:

• A typed mechanism-specific representation of a principal name

• A chain of identity certificates representing the subject and a chain of verifying authorities

• A distinguished name

• The anonymous principal identity (a type, not a name)

   An identity_token is used to assert a caller identity when that identity differs from the identity proven by authentication in the authentication layer(s). If the caller identity is intended to be the same as that established in the authentication layer(s), then it does not need to be asserted in an identity_token.

   • client_authentication_token

   Carries a mechanism-specific GSS initial context token that authenticates the client to the TSS. It contains a mechanism type identifier and the mechanism-specific evidence (that is, the authenticator) required by the TSS to authenticate the client.

   When an initial context token contains private credentials, such as a password, this message may be safely sent only after a confidential connection with a trusted TSS has been established. The determination of when it is safe to send a client authentication token in an EstablishContext message shall be considered in the context of the CORBA location-binding paradigm for persistent objects (where an invocation may be “location forwarded? by a location daemon to the target object). This issue is considered in Section 24.5.3, “Client-Side Requirements and Location Binding,? on page 24-44.

   When a TSS is unable to validate a security attribute service context, the TSS shall not dispatch on the target object method invocation. The TSS shall reply with a ContextError message that carries major and minor codes indicating the reason for the failure.

   If an EstablishContext message contains an identity token, then it is the responsibility of the TSS to extract a principal identity from the identity token and determine if the identity established in the authentication layer(s) is trusted to assert the extracted identity. If so, the asserted identity is used as the caller identity in the target’s authorization determination.

   The processing of a request to establish a context that arrives on a one-way call shall be the same as an ordinary call, except that the TSS will not send an indication of the success (CompleteEstablishContext) or failure (ContextError) of the context validation.

   24.2.2.2 ContextError Message Format

   A ContextError message is sent by a TSS in response to an EstablishContext or MessageInContext message to indicate to the client that the TSS detected an error. Section 24.3.4, “CSS State Machine,? on page 24-27 defines the circumstances under which a TSS returns specific error values and exceptions. The ContextError message contains the following fields:

   • client_context_id

   The value of the client_context_id that identifies the CSS context in the EstablishContext or MessageInContext message in response to which the ContextError is being returned.

   • major_status

   The reason the TSS rejected the context.

   • minor_status

   A more specific error code that further defines the reason for rejection in the context of the major status.

   • error_token

   A GSS mechanism-specific error token. When an EstablishContext message is rejected because it contains a client_authentication_token (a GSS initial context token) that is invalidated by the TSS, then depending on the mechanism, the TSS may return a CDR encapsulation of a mechanism-specific GSS error token in this field. Not all GSS mechanisms produce error tokens in response to initial context token validation failures.

   In all circumstances where a TSS returns a ContextError, the GIOP request that carried the rejected SAS context shall not be dispatched by the target ORB.

   24.2.2.3 CompleteEstablishContext Message Format

   A CompleteEstablishContext message is sent by a TSS in response to an EstablishContext message to indicate that the context was established. The CompleteEstablishContext message contains the following fields:

   • client_context_id

   The CSS allocated identifier for the security attribute context. It is returned by the target so that a stateful CSS can link this message to the EstablishContext request. A TSS shall always return the value of the client_context_id it received in the EstablishContext message.

   • context_stateful

   The value returned by the TSS to indicate whether or not the established context is stateful, and thus reusable. A stateless TSS shall always return false. A stateful TSS shall return true if the established context is reusable. Otherwise a stateful TSS shall return false.

   • final_context_token

   The GSS mechanism-specific final context token that is returned by a TSS if the client requests mutual authentication. When a TSS accepts an EstablishContext message containing an initial context token that requires mutual authentication, the TSS shall return a mechanism-specific final context token. Not all GSS mechanisms support mutual authentication, and thus not all responses to initial context tokens may include final (or output) context tokens.5

   When a CompleteEstablishContext message contains a final_context_token, the token shall be applied (with GSS_Init_sec_context) to the client-side GSS state machine.

   Two or more stateful SAS contexts are equivalent if they are established over the same transport layer connection or association, have the same non-zero client_context_id and have byte-equivalent identity, authorization, and authentication tokens.

   A multithreaded CSS may issue multiple concurrent requests to establish (that is, with an EstablishContext message) an equivalent stateful SAS context.

   A TSS shall not create a duplicate stateful SAS context in response to a request to establish a context that is equivalent to an existing context.

   A TSS shall return an exception containing a ContextError service context element if it receives a stateful EstablishContext message with a client_context_id that matches that of an existing context (established over the same transport layer connection or association) and for which any of the security tokens arriving in the message are not byte-equivalent to those recorded in the existing context. The request shall also be rejected. The exception and error values to be returned are defined in Section 24.3.4, “CSS State Machine,? on page 24-27.

   5. SAS layer authentication capabilities are designed to authenticate client to server where such authentication did not occur in the transport. The SAS protocol is predicated on server-to-client authentication having occurred in the transport layer, and in advance of the request. Server-to-client authentication in service context (which requires that the target return a final_context_token) is not the typical use model for SAS layer authentication capabilities.

   Table 24-1 CompleteEstablishContext Message Semantics

   24.2.2.4 MessageInContext Message Format

   A MessageInContext message is used by a CSS that wishes to reuse an existing context with a request. A CSS may also use this message to release context that it has established with a stateful TSS. The MessageInContext message contains the following fields:

   • client_context_id

   The nonzero context identifier allocated by the client in the EstablishContext message used to create the context.

   • discard_context

   A boolean value that indicates whether the CSS wishes the TSS to discard the context after it processes the request. A value of true indicates that the CSS wishes the context to be discarded, a value of false, indicates that it does not. The purpose of the discard_context field is to allow a CSS to help a TSS manage the cleanup of reusable contexts.6

   Any request message may be used to carry a MessageInContext message to a target. A TSS that receives a MessageInContext message shall complete the processing of the request before it discards the context (if discard_context is set to true).

   A TSS may receive a MessageInContext message that refers to a context that does not exist at the TSS. This can occur either because the context never existed at the TSS or because it has been discarded by the TSS. In either case, the TSS shall return an exception containing a ContextError service context element with major and minor

   6.Stateful clients are under no obligation to manage TSS state, so their use of this message for that purpose is discretionary.

   error codes indicating that the referenced context does not exist. The exception and error values to be returned are defined in Section 24.3.4, “CSS State Machine,? on page 24-27.

   The processing of a MessageInContext message that arrives on a one-way call shall be the same as for an ordinary call, except that the TSS will not return a ContextError when the referenced context does not exist.