Intel® SOA Expressway as Secure Token Service for Lightweight Clients

Most of you are familiar with deploying Intel® SOA Expressway as a xml gateway for protecting your SOAP and REST services. I wanted to blog about another very interesting use case where SOA Expressway acts as a Secure Token Service (STS) for a lightweight client requestor.

While a formal STS generally assumes WS-Trust aware clients and SOAE can support that, this need not be the case and imposes additional requirements on a lightweight client. Instead of a formal WS-Trust request, the client can pass a simple credential in the form of a username/password token and retrieve the proper token for the web service they are trying to access. As long as we are sticking with common standards such as HTTP, HTTP Basic Authentication and SSL, WS-Trust isn’t necessary for simple cases.  In the model proposed here, Expressway is acting as a STS used to broker the authentication between a lightweight client and web service requiring a SAML assertion.   

The STS is trusted by both the client and the service and it negotiates the authentication between the two.  The client trusts the STS and doesn’t need to apply additional processing on the returned SAML assertion. Instead, it invokes the target service and treats the assertion as opaque.

The following diagram shows how Expressway can be deployed as an STS:

In this scenario, the client initiates a token request to the STS (Expressway) along with their identity in an acceptable form, such as username and password. In this example, we are assuming client is sending a username/password token and trusts the STS over a one-way SSL connection. These requirements provide the minimum level of security required yet don’t impose onerous WS-Security or WS-Trust requirements on a lightweight client. The STS authenticates and validates the client’s credentials and issues a security token such as a SAML token back to the client. Generally as a good practice, the STS will sign the token to prevent token tampering after it was issued. The STS then sends the token back to the client. With the SAML assertion in hand, the lightweight client now forwards the web service request along with the trusted security token issued by the STS. The target Web Service validates the security token and confirms that the token was issued by trusted STS and sends the web service response if everything looks good.

As many of you are familiar with, SOA Expressway exposes an AAA action in Services Designer that can be used in your workflow to implement the functionality for SOAE to be a STS for your environment. AAA action provides a lot of flexibility in terms of different token types that are supported, e.g. HTTP Basic Authentication, UsernameToken, SSL certificate etc. We can configure SOAE to authenticate clients against a variety of Identity Management solutions supported such as Microsoft’s Active Directory, CA’s Site Minder or Oracle’s Identity Management products such as OIM and OAM. SOAE can then issue a token such as a SAML assertion, sign it and send it to the client. Client can then make the web service call with the token.

Following screenshot demonstrates our AAA policy with an example. In this example, SOAE, our STS is expecting a username and password in HTTP Basic Authentication header from the client. It will then authenticate the user with the LDAP server configured in the AAA policy. After client has been validated, SOAE will generate a SAML token and sign it before it is returned to the client.

The STS workflow is shown in the screenshot below.

    • The Receive action is for SOAE to receive a HTTP request from the client with username and password in Basic Authentication header.

    • The AAA Action invokes the AAA policy shown in Figure b using the client’s credentials and if the client is authenticated, creates a signed SAML assertion. The catch block is included in the workflow for Error Handling. It catches any authentication failures in the policy such as invalid credentials, missing credentials etc. In case of an authentication exception, SOAE returns 401 Unauthorized error back to the client.

    • The Reply action returns the SAML assertion back to the client.


Hope you find this blog helpful. You can get more information on SOAE at and a great primer on STS is at Please feel free to send me your comments and suggestions.

Para obtener información más completa sobre las optimizaciones del compilador, consulte nuestro Aviso de optimización.