Accessing Claim Aware Services using STS Secured with Non-repudiation

Usually, WSO2 Identity Server (IS) Security Token Service (STS) is secured using UsernameToken. By doing so, claims related to a particular user can be easily retrieved from a userstore.

However, there can be situations where STS is secured using non-repudiation, in which case the users are authenticated by signing the Request for Security Token (RST) using their private key. At the STS side, claims should be retrieved based on the user's X.509 certificate's Common Name (CN), if the STS trusts the user.

An extension point is used to address this scenario in WSO2 Identity Server. A custom attribute finder for non-repudiation scenario is written and given to IS to execute. This section discusses how to achieve this using WSO2 Identity Server and WSO2 Enterprise Service Bus. Additionally, an STS Sample is used which can be downloaded here. This sts-sample includes executables as well as the source files with an Eclipse project that was configured using Maven.

Use the following steps to run this scenario:

Adding a Custom Attribute Finder to IS

The following is the source code of a custom attribute finder. It simply parses the distinguished name of the certificate and extracts the value of CN, which is used as the identifier to query the user store for claims.

package org.wso2.carbon.identity.resource.sts.attributeservice.x509;
 
import org.apache.commons.logging.Log;
import org.apache.commons.logging.LogFactory;
import org.apache.rahas.RahasData;
import org.apache.rahas.impl.util.SAMLAttributeCallback;
import org.opensaml.SAMLException;
import org.wso2.carbon.identity.provider.AttributeCallbackHandler;
import org.wso2.carbon.identity.provider.IdentityAttributeService;
 
public class X509AttributeService extends AttributeCallbackHandler implements IdentityAttributeService {
 
    private static Log log = LogFactory.getLog(X509AttributeService.class);
 
    public void handle(SAMLAttributeCallback attrCallback) throws SAMLException {
        RahasData data = null;
        String userIdentifier = null;
        String[] splitArr;
     
        try {
                data = attrCallback.getData();
                splitArr = data.getPrincipal().getName().split(",")[0].split("=");
     
                if (splitArr.length == 2) {
                    userIdentifier = splitArr[1];
                    loadClaims(userIdentifier);
                    processClaimData(data, data.getClaimElem());
                    populateClaimValues(userIdentifier, attrCallback);
                }   
        }   
        catch (Exception e) {
            log.error("Error occuerd while populating claim data", e); 
        }   
    }   
}

You can download the compiled version of this - org.wso2.carbon.identity.resource.sts.attributeservice.x509-1.0.0.jar - from here.

Copy this into {IS_HOME}/repository/components/dropins folder.

Configuring Key Stores

The following steps generate a key pair for the particular user you are interested in client's key store, and add his/her certificate to IS' key store.

If you are using the key store of the sts-sample downloaded (which is located at sts-sample/src/main/resources/keystore/wso2carbon.jks), and if you want to test with the "admin" user, skip step 1.

1. Generate a new key pair in client's key store with the CN "admin" (or any other, if you want to test a different user in the IS user store).

   keytool -genkey -keyalg RSA -alias admin -keypass admin123 -keystore path/to/client/wso2carbon.jks -storepass wso2carbon -dname "CN=admin"

2. Generate a certificate from the key pair.

   keytool -export -alias admin -file path/to/admin.cert -keystore path/to/client/wso2carbon.jks -storepass wso2carbon

3. Import the new certificate to {IS_HOME}/repository/resources/security/wso2carbon.jks.

   keytool -import -alias admin -file path/to/admin.cert -keystore path/to/server/wso2carbon.jks -storepass wso2carbon

4. When it asks "Trust this certificate? [no]:" at the end of above command, enter yes.

Running the Servers

In ESB, change the "Offset" value to 1 in {ESB_HOME}/repository/conf/carbon.xml. This allows you to run both IS and ESB servers parallelly. IS runs on the default port 9443 and ESB on 9444.

Start both servers by executing the following:

Securing an Echo Service (the Relying Party) in ESB

1. Add a custom policy to the registry.
   1. Create a new collection (which is essentially a folder) to maintain custom policies.
       
   2. Add the service-policy.xml located at 'sts-sample/src/main/resources/' to this collection.
       
2. Secure the echo service with the custom policy.
   
   1. Go to the Services list and click the Unsecured link of the echo service.
       
   2. Select Yes in the "Enable Security?" option.
   3. Give the path of the policy file we uploaded to registry, in the Policy From Registry section at the end of the page.
      
   4. Click Next.
   5. In the following page, select wso2carbon.jks as the Trusted Key Store.
       

The end service is successfully configured now.

Add ESB's Echo Service as a Trusted Service of STS

In the Security Token Service page (Main > Manage > Security Token Service) of the WSO2 Identity Server, Add new trusted service with the following details:

Secure STS with Non-repudiation

1. Click Apply on the above screen.
2. Select "Yes" in the "Enable Security?" option.
3. Select scenario 2 - Non-repudiation, and click Next.
    
4. On the following page, as we did for ESB, select 'wos2carbon.jks' as the Trusted Key Store.