Tech Life of Recht

Yesterday, I wrote about how to implement an STS with Metro. The reason for implementing an STS in the first place is that it enables identity delegation, something you probably want if you need to access a service on behalf of a specific user. The general flow is that the user authenticates, probably using SSO of some kind, and access a website. The site invokes a service on behalf of the user, and the service needs to be pretty sure that the user is actually sitting in the other end, even though there is no direct communication between the user and the service. The job of the STS is to be the one, everybody trusts, so that when the STS issues a token which says that the user is valid, then the service can trust that this is actually the case.

All of this can be done more or less automatically with Metro (at least when using a nightly build) by using this service policy:

Here, we express that the service requires an issued token of type SAML 2.0. Issued token means that the token has been created by an STS. In this case, we specify that the STS identified by urn:localsts must issue a token of type SAML 2.0. The exact location of the STS needs to be configured in the client.

Unfortunately, WS-SecurityPolicy does not make it possible to express the requirements for the WS-Trust Issue request. When using identity delegation, two sets of credentials should be passed to the STS: The client credentials, for example an X509Token or a UsernameToken, and the user credentials. The client credentials are provided using standard WS-Security mechanisms, and the user credentials are included in the Issue request using the ActAs element.

As shown in the STS example, the STS policy file takes care of the client credentials by specifying the appropriate tokens. The user credentials token cannot, however, be expressed in the policy, so it needs to be agreed upon out of band. This also means that you have to provide it manually to the client.

Luckily, it's pretty easy to add an ActAs token to the client. Normally, the client is generated using wsimport. In this example, the service is called ProviderService:

Here, we create a new configuration object, set the endpoint information for the STS, and add an ActAs token. The contents of the ACT_AS attribute should be an instance of com.sun.xml.ws.security.Token, for example a com.sun.xml.wss.saml.Assertion. Normally, you don't generate the token yourself. Instead, you get it as part of the initial authentication response - for example, if you're using SAML 2.0 web SSO, one of the attributes received might be the ActAs token that should be passed to the STS when invoking services.