Secure Federation

This pattern permits members of a federation participate in a circle of trust. It allows assigning roles to users / services of their organisation in the context of a B2B collaboration. It provides a mechanism to dynamically bootstrap or exclude participants of the collaboration (i.e. group members), and to accordingly update security context of the group on-the-fly.

In a typical cross-enterprise collaborative scenario, performing an activity requires participants (users, services, resources) to be provided by different enterprises. A demand for including new participants will appear during the collaboration lifetime, and the existing participants may be dropped.

At the same time, security of the collaboration needs to be maintained: members of a federation must be able to identify one another, identify messages as coming from other members of the federation, and identify the truth of claims made by other parties in the federation.

It is appropriate to apply this pattern:

When interacting entities are exposed via Web Services interfaces and can understand WS-Trust and WS-Coordination standards.
For establishing on-the-fly mechanism to dynamically bootstrap or exclude participants of the collaboration.

To provide a security baseline for a distributed transaction of Web services, which is independent of the transactions business logic, where transactions can be of varied nature (atomic transaction, business activity, or business process).
When the requestor directly invoking a service does not know/have in advance the specific rights and privileges required for the interaction.
When:
- Dynamic federative collaborations of participants belonging to different enterprises is required.
- Collaborative group needs to be secure from outsiders, and from past members; also, group; members must not be able to talk to outsiders in the context of the group.
- Mechanism needs to provide peer-authentication and authorisation, and message confidentiality and integrity.
- Participants may be introduced dynamically, which has to be done in a secure way.
- Past group members are prevented from interactions within the group, by: their (SOAP) interceptor is re-configured, and the security context of the group is updated.

The architectural model assumed in the pattern is depicted in the next Figure - Secure Federation.
The initial assumption is that every entity in the model already owns a key pair and an identity token provided by the environment (i.e. a trust realm) they reside in. A token contains owners ID, public key, etc. These tokens can be attached to every message when authenticating a requester at the destination is required.
As an example, an identity token owned by web service 1 is: Tws1 = (WS1_ID, Puws1,) signPrsts ,where WS1_ID is the identifier of the service1.

The Security Token Service (STS) that signs and issues these identity tokens may be different from the one which is subsequently involved in the creation of the security context. With that respect, the assumption is that there is a predefined relationship between the coordination service and the STS responsible for creating the key-pair for the group and the group token. This token is signed by a private key of that STS, and contains at least the groupID, an identifier of the service and the group public key: Tgws1 = {GroupID, IDws1, Pug,}/signPrsts

This basic participants in the pattern are:

Coordinator: it provides a mechanism for creation and automated propagation of the contextual information, which in turn can support: separation of the members of different groups, and scoping of the functions/actions of the security services for the given context. It may consists of:
- Activation service , with an operation that enables an application to create a coordination instance or context. Once a coordination context is acquired by an application, it is then sent by whatever appropriate means to another application. The context contains the necessary information to register into the activity specifying the coordination behaviour that the application will follow.
- Registration service , with an operation that enables an application to register for coordination protocols. The Registration service of the original application or an application may use one that is specified by an interposing, trusted, coordinator. This way, an arbitrary collection of network services may coordinate their joint operation.
- A coordination type -specific set of coordination protocols, which define the coordination behaviour and the messages exchanged between the coordinator and a participant playing a specific role within a coordination type.

Security Token Service (STS) refers to a component that can issue, validate and/or exchange security tokens, which are effectively a signed collection of claims about a particular member of a trust realm. There is at least one STS associated with a trust realm, and several entities within the same realm may use the same STS.
Policy Decision Point (PDP) refers to a network node that makes decisions on the basis of already defined declarative security policies.
Policy Enforcement Point (PEP) refers to any mechanism that enforces a (security) policy of a trust realm on a network entity. A PEP is deployed on behalf of a resource owner, service provider or user and typically will implement at least one of the following security behaviour patterns: A message inspector checks the correctness of the message including validation of any tokens expressing security claims; A message interceptor / security intermediary (actor) / gateway provides the main point where processing and transformation of message content is performed and a policy decision is enforced; A Secure message router manages secure and reliable message propagation to intermediaries and ensures that they will be able to process only the information portion / message segments that are necessary for their role, the rest of the message being made confidential.