24.3.3 TSS State Machine

    The TSS state machine is defined in the state diagram, Figure 24-3 on page 24-24 and in the TSS state table, Table 24-6 on page 24-25. Each TSS call thread shall operate independently with respect to this state machine. Where necessary, thread synchronization at shared state shall be handled in the actions called by this state machine.

   An ORB must not invoke the TSS state machine if the target object does not exist at the ORB. The TSS state machine has no capacity to reject or forward8 a request because the target object does not exist, and must rely on the ORB to only invoke the TSS when the target object exists at the ORB.

   In response to a one-way call, a TSS shall not perform any of the send actions described by the state machine.

    The shaded rows in Table 24-6 on page 24-25 indicate transitions and states that do not exist in a stateless implementation of the SAS protocol.

   The state names, function names, and function signatures that appear in the state diagram and the state table are not prescriptive.

   8.A TSS uses the LOCATION_FORWARD status to return an IOR containing up-to-date security mechanism configuration for an existing object.

   Figure 24-3 TSS State Machine

   Table 24-6 TSS State Table

   24.3.3.1 TSS State Machine Actions

   This section defines the intended semantics of the actions appearing in the TSS state machine. As noted above, the function names and function signatures are not prescriptive.

   • accept_context (tokens, N, Out stateful)

   This action validates the security context captured in the tokens including ensuring that they are compatible with the mechanisms supported by the target object. If a context is not validated, accept_context returns error codes that describe the reason the context was rejected.

   When called by a stateless TSS, accept_context always returns false in the output

   argument “stateful.? When called by a stateful TSS, accept_context may (depending on the effective policy of the target object) attempt to record state corresponding to the context. If state for the identified context already exists and the received tokens are not equivalent to those captured in the existing context, accept_context shall reject the context. If the context state either already existed, or was recorded, accept_context returns true in the output argument “stateful.?

   An implementation of accept_context shall implement the error semanticsdefined in the following table.

   Table 24-7 Accept Context Error Semantics

   When accept_context returns any of Invalid evidence, Conflicting evidence, or Invalid mechanism, the TSS shall reject the request and send a NO_PERMISSION exception containing a ContextError service context element with error codes as defined in Table 24-9 on page 24-31. When accept_context returns Policy change, the TSS action shall reject the request and return a reply with status LOCATION_FORWARD and containing a new IOR for the target object that contains an up-to-date representation of the target’s security mechanism configuration.

   • accept_transport_context()

   This action validates that a request that arrives without a SAS protocol message; that is, EstablishContext or MessageInContext satisfies the CSIv2 security requirements of the target object. This routine returns true if the transport layer security context (including none) over which the request was delivered satisfies the security requirements of the target object. Otherwise, accept_transport_context returns false. When accept_transport_context returns false, the TSS shall reject the request and send a NO_PERMISSION exception.

   • reference_context ( N ) If there is an existing context with client_context_id = N, reference_context

   returns a reference to it. Otherwise, reference_context returns an empty reference.

   • discard_context ( N )

   If context N exists and it is not needed to complete the processing of another thread, discard_context causes the context to be deleted.