Previous | Table of Contents | Next |
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
client_context_id in EstablishContext Message0N != 0 |
client_context_id in CompleteEstablishContext Message |
context_stateful in CompleteEstablishContext Message |
Semantic |
||
0 | False | Client requested stateless context. | |||
N | False | TSS is stateless or TSS did not choose to remember context. In either case, if the client attempts to reuse the context (via MessageInContext) it should expect to receive an error. | |||
True | Stateful TSS accepted reusable context. |
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.