Apache CXF STS articles

Two of my colleagues have written excellent articles on the forthcoming STS (Security Token Service) implementation in Apache CXF, complete with sample projects. See here for the article from Oliver Wulff, and here for the article from Glen Mazza.

Using Kerberos with Web Services - part I

This is the first of a two-part series on using Kerberos with Web Services, with Apache WSS4J and CXF. WSS4J 1.6.2 adds support for obtaining a Kerberos ticket from a KDC (Key Distribution Center) and converting it to a BinarySecurityToken to be inserted into the security header of a SOAP request. On the receiving side, support has been added to validate the received Kerberos ticket accordingly. CXF 2.4.2 extends the Kerberos functionality available in WSS4J 1.6.2 to add support for WS-SecurityPolicy. No support is available yet (as of CXF 2.4.2) to use a secret key to sign and encrypt message parts, this will be the subject of part II.

In this post we will talk about installing the MIT Kerberos distribution in Ubuntu, and creating the necessary credentials to run some tests. Then we will go into some system tests in CXF that show how a client can get a Kerberos AP-REQ ticket from a KDC and send it to a service provider, who then authenticates the ticket, all driven by some spring configuration and WS-SecurityPolicy.

1) Installing MIT Kerberos

1.1) Installing the product

In this section we cover how to install the MIT Kerberos distribution in Ubuntu. This is needed to run the CXF Kerberos system tests. See here for more information on using Kerberos on Ubuntu. Open a command prompt and type:

sudo apt-get install krb5-kdc krb5-admin-server

When the product is installing you'll be asked for the default Kerberos Version 5 realm. Enter:

WS.APACHE.ORG

You will then be prompted for the hostnames of Kerberos servers in the WS.APACHE.ORG Kerberos realm. As we are installing the KDC and running the tests on the same machine, we only need to enter "localhost". Similarly, enter "localhost" when prompted for the Administrative server for the Kerberos realm.

1.2) Modifying configuration

Once apt-get has finished, we need to modify the Kerberos configuration file ("sudo vi /etc/krb5.conf"):

• Under the "[realms]" section, add a "default_domain" entry for ws.apache.org. The entire entry should look like:
  

  WS.APACHE.ORG = {
               kdc = localhost
               admin_server = localhost
               default_domain = ws.apache.org
  }

• Under the "[domain_realm]" section, add the following:     

ws.apache.org = WS.APACHE.ORG  
.ws.apache.org = WS.APACHE.ORG

• Finally, add a logging section:

[logging]

        kdc = FILE:/var/log/krb5kdc.log
        admin_server = FILE:/var/log/kadmin.log
        default = FILE:/var/log/krb5lib.log

1.3) Create principals

The next step is to create some principals. Create a master key via:

sudo kdb5_util create -s

The next step is to start kadmin locally via:

sudo kadmin.local

If you run "listprincs" at the prompt you should see the ticket-granting-ticket principal "krbtgt/WS.APACHE.ORG@WS.APACHE.ORG". We will add a client principal and service principal:

addprinc alice
addprinc bob/service.ws.apache.org

"quit" the kadmin prompt, and start the KDC with "sudo krb5kdc". If you see no error messages then everything should be working correctly. To test this try to get a ticket for "alice" via "kinit alice", entering the password given when creating the "alice" principal.

1.4) Create keytabs

To avoid having to enter passwords when running the tests, we will create Keytabs. Start kadmin.local again ("sudo kadmin.local"), and enter:

ktadd -k /etc/alice.keytab alice
ktadd -k /etc/bob.keytab bob/service.ws.apache.org

To check that the keytabs were create correctly, you can inspect them with klist, e.g. "sudo klist -k /etc/alice.keytab". Finally make sure the keytabs are readable via "sudo chmod og+r /etc/*.keytab" - obviously this is not secure, but it is sufficient for this test application.

2) Running the Kerberos system tests in Apache CXF

Now that we have installed Kerberos and created the relevant principals, we can run the Kerberos system tests in Apache CXF. These tests are @Ignore'd by default. The KerberosTokenTest contains a number of different Kerberos tests. In this article we will just examine the tests that involve obtaining a Kerberos Token, and not any of the tests that involve using the secret key associated with a Kerberos Token to secure some part of the request.

Firstly, make sure that the JDK has unlimited security policies installed, and then checkout the CXF trunk via:

svn co https://svn.apache.org/repos/asf/cxf/trunk/

Go into the "trunk" directory, and compile and install CXF via "mvn -Pfastinstall" (this will avoid running tests). Finally go into the WS-Security system tests in "systests/ws-security". Open KerberosTokenTest.java and comment out the "@org.junit.Ignore" entries for the first four tests, "testKerberosOverTransport", "testKerberosOverSymmetric", "testKerberosOverSymmetricSupporting" and "testKerberosOverAsymmetric". Finally, run the tests via:

        mvn test -Dtest=KerberosTokenTest -Djava.security.auth.login.config=src/test/resources/kerberos.jaas

2.1) WS-SecurityPolicy configuration

The wsdl that defines the service endpoints contains WS-SecurityPolicy expressions that define the security requirements of the endpoints. The following security policies are used for the four tests defined above:

• testKerberosOverTransport: A (one-way) transport binding is defined, with a KerberosToken required as a SupportingToken. Essentially, this means that the communication is secured with TLS, and authentication is handled by a Kerberos token.
• testKerberosOverSymmetric: A symmetric binding is used, where a KerberosToken is required as a SignedSupportingToken. 
• testKerberosOverSymmetricSupporting: A symmetric binding is used, where a KerberosToken is required as a SupportingToken.
• testKerberosOverAsymmetric: An asymmetric binding is used, where a Kerberos token is required as a SignedSupportingToken.

The WS-SecurityPolicy expression used for a KerberosToken is:

<sp:KerberosToken sp:IncludeToken=".../Once">
    <wsp:Policy>
        <sp:WssGssKerberosV5ApReqToken11/>
    </wsp:Policy>
</sp:KerberosToken>

This means that a GSS V5 AP-REQ Token is required "once", in other words the initial invocation between the client and service endpoint must contain a token of this type encoded as a BinarySecurityToken in the security header of the request.

2.2) Kerberos LoginModule configuration

Both the CXF client and service endpoint use JAAS to authenticate to the KDC. The JAAS file used as part of the system test is passed to the tests via the System property "java.security.auth.login.config". The client (alice) uses the following login module:

alice {
    com.sun.security.auth.module.Krb5LoginModule required
    refreshKrb5Config=true useKeyTab=true keyTab="/etc/alice.keytab" 
    principal="alice";
};

and the service endpoint (bob) uses:

bob {
    com.sun.security.auth.module.Krb5LoginModule required
    refreshKrb5Config=true useKeyTab=true storeKey=true
    keyTab="/etc/bob.keytab" principal="bob/service.ws.apache.org";
}; 

2.3) Service endpoint configuration

The service endpoints are spring-loaded. Each endpoint definition contains the JAX-WS property "ws-security.bst.validator" which is defined in SecurityConstants. WSS4J uses Validator implementations to perform validation on received security tokens. This particular property means that BinarySecurityTokens are to be validated by the given reference, e.g.:

<jaxws:endpoint ...>  
    <jaxws:properties>      
        <entry key="ws-security.bst.validator" value-ref="kerberosValidator"/>
    </jaxws:properties>
</jaxws:endpoint>

"kerberosValidator" is defined as:

<bean id="kerberosValidator"
    class="org.apache.ws.security.validate.KerberosTokenValidator">
    <property name="contextName" value="bob"/>
    <property name="serviceName" value="bob@service.ws.apache.org"/>
</bean>

The KerberosTokenValidator class ships with Apache WSS4J. It requires a "contextName" property, which corresponds to the JAAS context name, as well as an optional "serviceName" property. Combined with the JAAS properties file, this is all that is required for the service endpoint to validate a received Kerberos Token. 

2.4 Client configuration

Finally, the client must contact a KDC and obtain a Kerberos Token, once it sees that the service endpoint has a security policy that requires a KerberosToken. The client configuration is available here. A sample configuration for the Kerberos Test case is as follows:

<jaxws:client name="{...}DoubleItKerberosTransportPort"
       createdFromAPI="true">
       <jaxws:properties>
           <entry key="ws-security.kerberos.client">
               <bean class="org.apache.cxf.ws.security.kerberos.KerberosClient">
                   <constructor-arg ref="cxf"/>
                   <property name="contextName" value="alice"/>
                   <property name="serviceName" value="bob@service.ws.apache.org"/>
               </bean>           
           </entry>
       </jaxws:properties>
</jaxws:client>

The JAX-WS property "ws-security.kerberos.client" (again, defined in SecurityConstants) corresponds to a KerberosClient object. Similar to the KerberosTokenValidator on the receiving side, this is configured with a JAAS context Name and service Name.

Improving decryption performance in Apache Santuario 1.5

Andreas Veithen alerted me some months back to a performance problem in Apache Santuario when decrypting messages. The issue emerged when some profiling was done on Dennis Sosnoski's test-code for measuring WS-Security performance across different web services stacks (see the original article here).

The test scenario involves deploying an Apache CXF 2.4.2 endpoint in Tomcat and repeatedly testing the "signencr" invocation defined in the article (WS-Security signing of body and headers, with timestamp and encryption of body) using a CXF client. Two types of test-runs were executed, 1000 "large" messages at 0.2 density in one run, and 10000 "small" messages at 0.05 density in another. When doing some profiling using a sampling profiler on the client, it emerged that the time it took to deserialize a decrypted XML String into a DOM element was taking around 20% of the total execution time for all WS-Security processing!

The way the default deserializing algorithm works in Apache Santuario 1.4.x is to parse the decrypted XML String into a new Document object, which is then imported into the existing Document. As Apache Xerces defers the creation of Node objects, the import operation triggers the full expansion of the DOM tree.

There are a number of alternatives to using the DocumentBuilder/importNode approach used in Santuario 1.4.x. The first approach is to use a Transformer object to transform the Source (XML String) into a placeholder Node belonging to the existing Document. This approach avoids having to explicitly import the nodes back to the existing Document. The second approach, is to use the streaming API available in the JDK 1.6 (not an option for Santuario 1.5 which must compile against the JDK 1.5).

Here are some (ad-hoc) test results. The first results show the total time for each test-run using both algorithms:

• Large Messages:
• Document Serializer: 119.46s
• Transform Serializer: 115.68s

• Small Messages:
• Document Serializer: 222.32s
• Transform Serializer: 216.76s

The next results show the time spent in the Serializer.deserialize() operation as a percentage of the total WS-Security processing time:

• Large Messages:
• Document Serializer: 19.92%
• Transform Serializer: 18.04%

• Small Messages:
• Document Serializer: 24.54%
• Transform Serializer: 18.36%

The Serializer interface is now public, and a different implementation can be set on XMLCipher. Two implementations are provided in the code, DocumentSerializer (the default algorithm) and TransformSerializer. If anyone is interested in running experiments of their own, the StreamSerializer algorithm is available here. The TransformSerializer implementation is not the default as it requires Xalan to work properly, and as this library is optional in Santuario 1.5.

Do you have any suggestions on how this could be improved further? Clearly, the time it takes to deserialize a decrypted XML String into a DOM node still takes far longer than it should. A fully StAX approach for XML Security would surely offer much improved performance - this is under development and planned for next year.

Apache WSS4J 1.6.3 released

Apache WSS4J 1.6.3 has been released. It can be downloaded here and the issues fixed are listed in the WSS4J JIRA.

Probably the most significant part of this release is that WSS4J now fully supports the Kerberos Token Profile 1.1. In the previous release, support was added to retrieve a Kerberos token from a KDC, and insert it into the security header of a request, and then validate it accordingly on the receiving side. In WSS4J 1.6.3, support has been added to use the secret key associated with the Kerberos token to sign and encrypt the request, and to verify and decrypt on the receiving side. I am planning on writing a series of blog posts soon about how to use Kerberos with WSS4J and CXF. The forthcoming Apache CXF 2.4.3 release will have full WS-SecurityPolicy support for working with Kerberos, based on the work done in WSS4J 1.6.3.

In addition to the Kerberos work, WSS4J 1.6.3 features an upgraded Opensaml dependency, as well as several bug fixes.

Talend donates Security Token Service (STS) to Apache CXF

I am pleased to announce that Talend has donated a Security Token Service (STS) implementation to Apache CXF, which will be part of the forthcoming 2.5 release. Since the 2.4.0 release, CXF ships with an STS framework (in the ws-security module), as well as a simple implementation of the framework in the examples. The STS that Talend has donated to the community is a sophisticated implementation of the STS framework that builds on top of CXF's existing mature security functionality.

In future blog posts I will document the features of the STS and how to configure it, as well as walk through some system tests. Here are some of the features and standards that the new STS supports:

• WS-Trust 1.3/1.4
• WS-SecurityPolicy 1.3
• Authentication Mechanisms for a RST: UsernameToken, SAML token (1.1/2.0), KerberosToken, X.509 Token.
• Security Binding supported: Symmetric, Asymmetric, Transport 
• Supports WS-Trust Issue/Validate and Cancel binding 
• Can issue the following tokens: SAML 1.1/2.0 Holder-Of-Key/Bearer, SecurityContextTokens, Custom Tokens.
• Issued token can be encrypted 
• Validate binding supports issuing a new token (token transformation).
• Custom Validators can be implemented 
• Creation of SAML tokens can be customized.
• Advanced RST elements: KeyType (Public, Symmetric, Bearer), Entropy (Symmetric, Public) , OnBehalfOf, ActAs, Claims, SecondaryParameters
• Pluggable claims handling and management

Specifying custom AlgorithmSuite policies in Apache CXF 2.4.3

When specifying a security binding via WS-SecurityPolicy, it is possible to define the algorithm suite via the "sp:AlgorithmSuite" policy. WS-SecurityPolicy defines a number of standard AlgorithmSuite policies, which control various security properties like the maximum and minimum Symmetric and Asymmetric key lengths, the encryption/signature/digest algorithms to use, etc. An example policy is given below. For this policy, the minimum symmetric key length is 256 bits, and the encryption algorithm is AES256:

<sp:AlgorithmSuite>
    <wsp:Policy>
        <sp:Basic256 />
    </wsp:Policy>
</sp:AlgorithmSuite>

There are certain scenarios where a user might want to use a non-standard AlgorithmSuite. For example, the minimum Asymmetric Key Length for all standard AlgorithmSuites is 1024 bits. This requires that the JDK has unrestricted security policies installed. If it is not possible to install unresticted security policies, a user might decide that using 512 bits RSA keys is sufficient (this is not recommended).

Apache CXF 2.4.3 provides support for specifying custom algorithm suites. A new interface is defined to create an AlgorithmSuite object given a policy, with a default implementation that supports the standard AlgorithmSuite policies. It is possible to create a new implementation of the AlgorithmSuiteLoader interface, and install it as a bus extension. For an example, there is a CXF system test that allows 512 bit asymmetric keys, with custom AlgorithmSuiteLoader and AlgorithmSuite implementations. The custom AlgorithmSuiteLoader implementation is spring-loaded, and registers itself as a bus extension.

SAML SecurityPolicy enforcement in CXF 2.4.2

Apache CXF 2.4.2 was released recently. In this blog post I want to delve into how CXF 2.4.2 enforces WS-SecurityPolicy expressions relating to SAML Assertions on the inbound side.

There are two policy expressions relating to SAML Assertions, the SamlToken and IssuedToken policy assertions. On the outbound side, the SamlToken expression will trigger a CallbackHandler to obtain a SAML Assertion to insert into the outbound security header, and the IssuedToken expression will use the STSClient to obtain a SAML Assertion from a Security Token Service (STS).

On the inbound side, any SAML Assertion received as part of the security header will be parsed initially by WSS4J. If the assertion is signed, then the signature is verified. If the confirmation method of the Subject of the Assertion is "holder-of-key", then WSS4J will parse the Subject KeyInfo and extract whatever credentials it can find, i.e. secret key or an X509Certificate. If no credential is found (or understood), then the default behaviour is to throw an exception. If the confirmation method is "holder-of-key", then the default behaviour (which is configurable) is to enforce that the Assertion is signed. Finally, WSS4J verifies trust in a certificate that was used to sign the assertion.

After WSS4J is done with validating a received SAML Assertion, CXF does some additional validation according to the configured security policy. For more information on any of the following terms (holder-of-key, sender-vouches, etc.), please consult the SAML Token Profile 1.1 specification.

1) SamlToken policy

If a SamlToken policy is used, the version of the received Assertion (1.1 or 2.0) is checked against the policy, e.g. if <sp:WssSamlV20Token11 /> is configured in the SAMLToken policy then the received Assertion must be a SAML 2.0 Assertion. Two checks are then done on the received Assertion, depending on what the subject confirmation method is.

• Holder-of-key: If the subject confirmation method is "holder-of-key", there must be some proof-of-possession of the key associated with the subject of the assertion. CXF will enforce that either the key was used to sign some portion of the SOAP request, or alternatively the subject credential of the SAML Assertion must match a client certificate credential when 2-way TLS is used.
• Sender-Vouches: If the subject confirmation method is "sender-vouches", then CXF will enforce that the SAML Assertion and SOAP Body are signed by the same signature. Alternatively, it will check that 2-way TLS is used.

2) IssuedToken Policy

If an IssuedToken policy is used, then the receiver is expecting to get a SAML Assertion that is issued by a third-party security service. If the subject confirmation method of the Assertion is "holder-of-key", then it does the same check as described above for a SamlToken policy. Additionally, if a "<sp:RequestSecurityTokenTemplate..../>" policy is configured, it will attempt to match the received Assertion against the RSTTemplate parameters:

• TokenType: If a TokenType parameter is specified in the template, it will match this against the version of the received Assertion. For example, if the TokenType is "http://docs.oasis-open.org/wss/oasis-wss-saml-token-profile-1.1#SAMLV1.1", then the Assertion must be a SAML 1.1 Assertion.
• KeyType: If a KeyType parameter is specified in the template which ends with "SymmetricKey", then the subject of the Assertion must contain a secret key. If the KeyType parameter ends with "PublicKey", then the Subject must contain a Certificate or PublicKey.

Here is an example of a RequestSecurityTokenTemplate:

<sp:RequestSecurityTokenTemplate>
    <t:TokenType>
      http://docs.oasis-open.org/wss/oasis-wss-saml-token-profile1.1#SAMLV1.1
   </t:TokenType>
   <t:KeyType>
     http://docs.oasis-open.org/ws-sx/ws-trust/200512/PublicKey
   </t:KeyType>
</sp:RequestSecurityTokenTemplate>

Issuer or IssuerName policies are not yet enforced, this will probably be done in a future version of CXF.