Broker Trust Relationships with WSO2 Identity Server

WS-Trust can be considered as an extension to WS-Security specification which primarily provides methods for managing security tokens and ways to broker the trust relationships. The Web Services trust model explained under the WS-trust specification defines three key participants:

• Security token service

• Service Consumer

• Service provider (Relying party)

Security token service (STS) is a Web Service that issues security tokens based on the requester's needs. The consumer sends token requests to the STS in addition to appending tokens into the actual service request and submitting them to the provider. The service provider makes the authentication decision on the service based on the token provided by STS. The service provider may also request token validations from the STS.

This sample includes step-by-step instructions on how WS-trust concepts can be used with WSO2 SOA middleware.

We are going to work on the basic trust establishment scenario in the context of WS-trust specification. A SOAP Web Service consumer requests for a security token from STS. We use WSO2 Identity Server as the token provider. WSO2 Identity Server includes a Security Token Service (STS) which is capable of generating security tokens to build trust relationships.

Once the consumer possesses the necessary security tokens, these tokens are presented in order to authenticate to a Web Service deployed in WSO2 Application Server.

Open

Pre-requisites:

1. Download and install WSO2 Identity Server

2. Download and install WSO2 Application Server

3. Any Java IDE (Eclipse, Idea)

4. soapUI (optional)

First, we need to figure out how we can start the end-to-end process. Obviously, the consumer initiates the process. But, how does the consumer know that he first needs to talk to a STS in order to consume the Web Service which is deployed in WSO2 application server?

The service provider needs to advertise those requirements through a WS-Policy. So, the starting point of our scenario is to configure a policy in the Web Service.

Then, we need to look into the token provider, WSO2 Identity Server. As I have explained before, WSO2 IS comes with a Security Token Service. We need to configure it to issue tokens to the provider Web Service and secure STS using a WS-Security policy because the consumers should authenticate themselves to the STS when requesting tokens.

Finally, we write a client/consumer (or just use a service invocation tool such as soapUI) to request a security token from STS and append it to the actual Web Service request message to authenticate to the Web Service which is deployed in WSO2 Application Server.

The following are the steps to follow in order to use this feature:

After this you simply need to run the client.

1. Start WSO2 Application Server and log in to the management console as a default admin user.

2. Go to Manage > Services > Add > AAR Service.

3. Deploy Axis2Service.aar which can be downloaded from here.

4. Once the service is deployed, we need to associate a security policy for our service. You can find a set of default Web Service security policies in security configuration wizard. However, you cannot use any of them for our scenario.

Our Web Service should be associated with a trust based security policy. A security token which is offered by STS represents a set of claims. A claim defines a specific information about a particular user. For example, first name or email address of the user.

In our example, Axis2Service (the Web Service deployed in service provider, WSO2 Application Server) needs to be made as a claim-aware Web Service. The users who consume the service need to present the claims defined in WS-Security policy.

Thus, we need to secure Axis2Service using a custom policy. You can download the complete policy from here. This is useful if you wish to look into the following element in the custom security policy.

SupportingTokens are used to provide additional claims for a requester (client). Use SupportingToken policy assertion to describe claims which should be given by a consumer to access this particular Web Service.

• The sp:IssuedToken element defines that the requester must talk to an STS to obtain the token.

• The sp:IncludeToken attribute value is defined as ../AlwaysToRecipient, which says the token must be included as part of all messages sent from the initiator (service consumer) to the recipient.

• The Address attribute of sp:Issuer element defines the token issuer whom the consumer must be contacted to get the security token. In other words, the endpoint address of the Security Token Service. In this scenario, it must be the STS URL of IS.

• The sp:RequestSecurityTokenTemplate element specifies the structure/type of the token which has to be issued by the STS. Later, you will observe the children of this element will be included as the part of RequestSecurityToken (RST) message which will be sent to the STS by consumer.

• The t:TokenType element represents the type of the token such as UserNameToken, SAML-1.1, SAML-2.0. In our example, we ask STS To generate SAML-2.0 token by specifying SAML-2.0 token type URL.

• t:KeyType represents the type of the key desired in security token, can be either public key, symmetric key or bearer. We will ask STS to generate the relatively simple key, bearer token. Bearer token does not require a proof of possession hence it is quite easy to dealt with.

• t:Claims element defines the claims that must be included in the security token. Request the First Name and Email address claims from the consumer.

The First Name claim is mapped to the "http://wso2.org/claims/givenname" URI. We are able to clear ourselves once we configure the token provider in the next step.

With this, we should have an understanding of all elements of the SupportingToken assertion of our custom Web Service policy. Let's upload the policy to embedded the registry in WSO2 Application Service.

1. Locate /_system/config collection in registry browser and click on Add Resource.

2. Navigate to the axis2service.policy.xml which you have downloaded from the above location.

3. Click Add. Now, we have our custom policy in WSO2 Application Server. We can associate the policy to Axis2Service.

4. Click on the Unsecured link associated with Axis2Service in the Deployed Services page. You are directed to the Security for the service page. 

5. Navigate to the Policy From Registry section which can be found at the bottom of the page. 

6. Click on the Configuration Registry icon and select the axis2service.policy.xml from the /_system/config collection.

7. Click on Next to proceed with the wizard. You are directed to the Activate Security page where you can specify a trusted key store for the Web Service.

8. Select wso2carbon.jks as the trusted key store. 

9. As discussed, STS is responsible for issuing tokens. Therefore, the STS is trusted by both the consumer as well as the service provider. In order to do this, the public key certificate of STS should be imported to the trusted key store defined. We do not explicitly do key exchanges in this example as we are using the same wso2carbon.jks keystore in both WSO2 Application Server and WSO2 Identity Server.

Now, we have our Web Service secured with a claim-aware security policy.

1. Start the WSO2 Identity Server.

2. Log in as an admin to access the management console. 

3. Do the following steps if you are using a Holder of Key confirmation method. See here for more information.

   1. Navigate to the Service Providers section by clicking Add in the Main menu under Service Providers.

   2. Add a Service Provider Name and Description and click Register.
      
      

      Open

      

   3. In the resulting page, expand the Inbound Authentication Configuration and the WS-Trust Security Token Service Configuration sections. Click Configure.

   4. Enter the trusted relying parties and upload the public certificate of the trusted relying party (against its end-point).

      
      The tokens issued are encrypted using the public key of the trusted relying party. Accordingly, even the client who obtains the token to send to the RP has no visibility to the included token.

   5. Click Apply.

4. Configure STS to add Axis2Service as a trusted service. Enter the HTTP endpoint url of the Axis2Service as the Endpoint Address.

5. Usually, the security token is signed by STS. Thus, it is necessary to select a certificate alias to sign the token. Select the default wso2carbon certificate alias.

6. Now, apply the security to the STS. To do this, do the following. 

   1. In the management console, click Resident under Identity Providers in the Main menu.

   2. In the resulting page, expand the Inbound Authentication Configuration section and the WS-Trust / WS-Federation (Passive) Configuration section.

   3. Click Apply Security Policy to configure security and go through the wizard.
      
      

      Open

      

7. Configure security and go through the wizard by using the following steps.
   
   

   1. Select Yes from the Enable Security? dropdown.

   2. Select UsernameToken from the Basic Scenarios list.
      
      

      Open

      

   3. Click Next.

8. Select admin as the user group and click on Finish.

9. Now, check the user profile of admin user who is going to authenticate to the STS. Click on My Profiles at the left menu. The Update Profile form displays where you can enter various user attributes such as First Name, Last Name, etc.

10. Make sure to add some values to the First Name and Email address fields since we are going to use those as the required claims.

11. Click on Configure in the left menu and select Claim Management. You find a set of claim dialects associated with the internal user store in IS. Click on the default claim dialect: http://wso2.org/claims. 

12. Click on the First Name claim mapping.

13. As you can see in the following screen, First Name is mapped to givenName attribute.
    
    

    Open