OIO Identity-based Web Services setup

OIO Identity-based Web Services setup


OIO Identity-based Web Services v1.0.1 (in short OIOIDWS) is a set of profiles for SOAP based web services developed by the Danish National IT and Telecom.
Agency and approved by the OIO Committee 1st October 2009. The profiles offer a standardized way to transfer claims about a subject (user) to a service provider.

As a teaser the figure below illustrates how the different profiles are used in a scenario where a user logs onto a service provider via the Web Single Sign On (OIOSAML). Following that the service provider sends a request to another web service provider on behalf of the user who is logged on


This profile is meant to be used in 2 major scenarios: The first is a website who needs to invoke an identity-based web service at a web service provider (WSP) on behalf of a (browser) user. In order to invoke the web service, the requester must first obtain an identity token representing the user from an STS, and subsequently place it in the web service call. Another important use of the profile is scenarios with "rich clients" that needs to invoke external web services on the user's behalf and therefore also need to obtain security tokens to gain access.

How does the OIO Identify STS work?

The new OIO Identify STS endpoint is deployed on runtime with address:

Processing rule

When receiving an issue request, STS must do the following:

  • Validate the signature, any certificates, any security tokens and timestamp of the request according to local policy.
  • The response MUST consist of exactly one \ element with exactly one \ element.
  • The response MUST be signed by the STS.

Those are basically supported on former Identify STS version except how to validate bootstrap token. It will be described on the next section.

How to validate bootstrap token

When processing an OIO issue request, if it presents a bootstrap token, this token will be validated it satisfies the following aspects:

  • Valid audiences restriction: List of valid entity IDs for each potential Security Token Service that may later be contacted by the service provider.
  • Trusted Issuers: List of valid trusted issuers who issued bootstrap token.
  • Assurance level required: the minimum assurance level used when issuing bootstrap token.
  • Assurance level claim type: the claim type of claim keeping issued assurance level.
  • Bootstrap token timestamp: it is the timeline in minutes for bootstrap token. Its default value is 60 minutes.

What are OIOIDWS Identify STS specifications?


It uses Liberty Basic soap binding. This section is defined on "Liberty basic soap binding 1.0" specification



Claims in request

Allow to add "requested claims": that means service provider can send a list of requested claims and Identify STS will combine between available and requested claims to generate the response.

Token format

Support SAML2.0 token profile for bootstrap token and do not specify token format for client credential.

Token lifetime

It depends on each local policy and is specified on the protocol connection for each service provider.

Test client scenario

There are 2 test scenarios - Active scenario and Passive scenario.

Active scenario


In this scenario, we have a Service A that needs to make a call to an operation in the Service B. Both services are expecting an token issued by an STS that they trust (The example assumes that they both trust the same STS). This is how "ActAs" works in this scenario.

  1. The client negotiates a SAML token with the STS for consuming the service A
  2. The client invokes an operation in the Service A using the SAML token it got from the STS as client credentials.
  3. Now, the Service A needs to invoke an operation in the Service B so it has to negotiate a new SAML token from the STS first. In order to do that, it includes the SAML token sent by the client as part of the ActAs element, and secures the message using any of the traditional WS-Security profiles. For example, Mutual Certificate, a client certificate for authenticating the client (Service A) and a service certificate for authenticating the service and protecting the messages. The STS issues a new token for consuming the service B using all the information received in the RST message.
  4. The service A invokes an operation in the Service B using the SAML token it just got from the STS as client credentials

Passive scenario


In this scenario, the Web Application authenticates all its user through an STS that implements the WS-Trust passive profile. This means that the web application is a claim-aware application that receives the user identity as claims from a token sent by the STS (The user first authenticates in the STS, step 1).

As the web application already has a token with the user claims, which is the token it received from the passive STS, it can include it as the ActAs element when it negotiates a SAML token from the Active STS (step 2).

Once the application gets a SAML token from the Active STS, it can actually use it for consuming the service (step 3).