Colm O hEigeartaigh

Some recent WS-Trust client topics in Apache CXF

Colm O hEigeartaigh - Wed, 10/08/2014 - 15:50
There are a number of minor new features and changes in recent versions of Apache CXF with respect to the client side of WS-Trust, which will be documented in this post.

1) STSClient configuration

CXF's STSClient is responsible for communicating with a Security Token Service (STS) via the WS-Trust protocol, in order to issue/validate/renew/etc. a security token. To support WS-Trust on the client side in CXF, it is necessary to construct an STSClient instance, and then reference it via the JAX-WS property key "ws-security.sts.client". Here is a typical example in spring.

However, there are some alternatives to configuring an STSClient per JAX-WS client object (see the CXF documentation for additional information). Strictly speaking these alternatives have been available in previous versions of CXF, however some bugs were fixed in the latest releases to enable them to work properly:

a) If no STSClient is directly configured on the JAX-WS client, then the CXF runtime will look for an STSClient bean with a name that corresponds to the Endpoint name with the suffix ".sts-client". Here is an example:

<bean id="stsClient" class="org.apache.cxf.ws.security.trust.STSClient"
    name="{http://www.example.org/contract/DoubleIt}DoubleItTransportSAML1Port.sts-client"
    abstract="true"
>

b) If no STSClient is configured either directly on the client, or else via the approach given in (a) above, then the security runtime tries to fall back to a "default" client. All that is required here is that the name of the STSClient bean should be "default.sts-client". Here is an example:

<bean id="stsClient" class="org.apache.cxf.ws.security.trust.STSClient"
    name="default.sts-client"
    abstract="true"
>

2) Falling back to Issue after a failed Renew

When a cached SecurityToken is expired, the STSClient tries to renew the token. However, not all STS instances support the renewal binding of WS-Trust. Therefore a new configuration parameter was introduced:
  • SecurityConstants.STS_ISSUE_AFTER_FAILED_RENEW ("ws-security.issue.after.failed.renew") -  Whether to fall back to calling "issue" after failing to renew an expired token. The default is "true".
 3) Renewing security tokens that are "about to" expire

There is a potential issue when a cached security token is "about to" expire. The CXF client will retrieve the cached token + check to see whether the token is expired or not. If it is expired, then it renews the token. If the token is valid, then it uses it in the service request. However, if the security token expires "en route" to the service, then the service will reject the token, and the service invocation will fail.

In CXF 2.7.13 and 3.0.2, support has been added to forcibly renew tokens that are about to expire, rather than risk letting them expire en route. A new configuration parameter has been introduced:
  • SecurityConstants.STS_TOKEN_IMMINENT_EXPIRY_VALUE ("ws-security.sts.token.imminent-expiry-value") - The value in seconds within which a token is considered to be expired by the client, i.e. it is considered to be expired if it will expire in a time less than the value specified by this tag.
The default value for this parameter for CXF 3.0.2 is "10", meaning that if a security token will expire in less than 10 seconds, it will be renewed by the client. For CXF 2.7.13, the default value is "0" for backwards compatibility reasons, meaning that this functionality is disabled.
Categories: Colm O hEigeartaigh

Apache CXF Authentication and Authorization test-cases III

Colm O hEigeartaigh - Tue, 10/07/2014 - 16:45
This is the third in a series of posts on authentication and authorization test-cases for web services using Apache CXF. The first post focused on authenticating and authorizing web service requests that included a username and password (WS-Security UsernameToken and HTTP/BA). The second article looked at more sophisticated ways of performing authentication and authorization, such as using X.509 certificates, using a SecurityTokenService (STS), using XACML and using Kerberos. This article will build on the previous articles to show how to perform Single Sign On (SSO) with Apache CXF.

The projects are as follows:
  • cxf-shiro: This project uses Apache Shiro for authenticating and authorizating a UsernameToken, as covered in the first article. However, it also now includes an SSOTest, which shows how to use WS-SecureConversation for SSO. In this scenario an STS is co-located with the endpoint. The client sends the UsernameToken to the STS for authentication using Apache Shiro. The STS returns a token and a secret key to the client. The client then makes the service request including the token and using the secret key to sign a portion of the request, thus proving proof-of-possession. The client can then make repeated invocations without having to re-authenticate the UsernameToken credentials.
  • cxf-sts:  This project shows how to use the CXF SecurityTokenService (STS) for authentication and authorization, as covered in the second article. It now includes an SSOTest to show how to achieve SSO with the STS. It demonstrates how the client caches the token after the initial invocation, and how it can make repeated invocations without having to re-authenticate itself to the STS.
  • cxf-saml-sso: This project shows how to leverage SAML SSO with Apache CXF to achieve SSO for a JAX-RS service. CXF supports the POST + redirect bindings of SAML SSO for JAX-RS endpoints. As part of this demo, a mock CXF-based IdP is provided which authenticates a client using HTTP/BA and issues a SAML token using the CXF STS. Authorization is also demonstrated using roles embedded in the issued SAML token. 
  • cxf-fediz-federation-sso: This project shows how to use the new CXF plugin of Apache Fediz 1.2.0 to authenticate and authorize clients of a JAX-RS service using WS-Federation. This feature will be documented more extensively at a future date, and is considered experimental for now. Please play around with it and provide feedback to the CXF users list.
Categories: Colm O hEigeartaigh

Apache Santuario - XML Security for Java 2.0.2 release

Colm O hEigeartaigh - Thu, 09/25/2014 - 17:33
Apache Santuario - XML Security for Java 2.0.2 has been released. This is a minor release that fixes a couple of bugs with the streaming code and contains a few dependency upgrades.
Categories: Colm O hEigeartaigh

New Apache Santuario releases

Colm O hEigeartaigh - Thu, 07/03/2014 - 23:17
Two new versions of the Apache Santuario - XML Security for Java project have been released. Version 2.0.1 (release notes) adds support for a number of previously unsupported algorithms, such as RSA with SHA-224, the RIPE-MD160 digest algorithm, and the RSASSA-PSS signature scheme. It also fixes a performance regression when evaluating signatures, a UTF-8 encoding issue with certain characters, an issue with using GCM algorithms with JDK 8, and a race condition in the streaming decryption code. Version 1.5.7 (release notes) contains the UTF-8, GCM and signature performance fixes, along with a number of other minor changes.
Categories: Colm O hEigeartaigh

Apache CXF Fediz 1.1.1 released

Colm O hEigeartaigh - Fri, 06/20/2014 - 13:31
Apache CXF Fediz 1.1.1 and 1.0.4 have been released. Fediz is a subproject of Apache CXF which implements the WS-Federation Passive Requestor Profile. It allows you to secure web applications using Single Sign-On (SSO) and Claims Based Access Control (CBAC), by redirecting users to an IdP (Identity Provider) for authentication, which in turn leverages the CXF STS (SecurityTokenService). Plugins are provided for the most popular web application containers, such as Apache Tomcat, Jetty, Spring, etc.

The 1.0.4 release  upgrades the underlying CXF dependency from 2.6.6 to 2.6.14, and the 1.1.1 release upgrades CXF from 2.7.7 to 2.7.11, thus picking up important bug fixes. Fediz 1.0.4 adds support for the wauth + whr parameters, while Fediz 1.1.1 adds support for wreq (see section 1.d below) and the older WS-Policy namespace, along with a few other bug fixes. See the Fediz JIRA for more information.
1) Fediz example

In a previous post introducing Apache CXF Fediz I gave instructions about how to deploy one of the Fediz 1.0.x examples to Apache Tomcat. In this section, I will update the deployment instructions for Fediz 1.1.1, as the examples have changed slightly since 1.0.x. In addition, I will give a simple example about how to use the new support for the "wreq" parameter added in Fediz 1.1.1 as part of FEDIZ-84 to request a SAML 1.1 token from the IdP.

Download the latest Apache CXF Fediz release (currently 1.1.1) here, and extract it to a new directory (${fediz.home}). It ships with two examples, 'simpleWebapp' and 'wsclientWebapp'. We will cover the former as part of this tutorial. We will use a Apache Tomcat 7 container to host both the Idp/STS and service application - this is not recommended, but is an easy way to get the example to work. Please see the associated README.txt of the simpleWebapp example for more information about how to deploy the example properly. Most of the deployment information in this section is based on the Fediz Tomcat documentation, which I recommend reading for a more in-depth treatment of deploying Fediz to Tomcat.

a) Deploying the IdP/STS

To deploy the Idp/STS to Tomcat:
  • Create a new directory: ${catalina.home}/lib/fediz
  • Edit ${catalina.home}/conf/catalina.properties and append ',${catalina.home}/lib/fediz/*.jar' to the 'common.loader' property.
  • Copy ${fediz.home}/plugins/tomcat/lib/* to ${catalina.home}/lib/fediz
  • Copy ${fediz.home}/idp/war/* to ${catalina.home}/webapps
Now we need to set up TLS:
  • Copy ${fediz.home}/examples/samplekeys/idp-ssl-server.jks to ${catalina.home}.
  • Edit the TLS Connector in ${catalina.home}/conf/server.xml', e.g.: <Connector port="8443" protocol="HTTP/1.1" SSLEnabled="true" maxThreads="150" scheme="https" secure="true" keystoreFile="idp-ssl-server.jks" keystorePass="tompass" clientAuth="false" sslProtocol="TLS" URIEncoding="UTF-8"  />
Now start Tomcat, and check that the STS is live by opening the STS WSDL in a web browser: 'https://localhost:8443/fediz-idp-sts/REALMA/STSServiceTransport?wsdl'

b) Deploying the service

To deploy the service to Tomcat:
  • Copy ${fediz.home}/examples/samplekeys/rp-ssl-server.jks and ${fediz.home}/examples/samplekeys/ststrust.jks to ${catalina.home}.
  • Copy ${fediz.home}/examples/simpleWebapp/src/main/config/fediz_config.xml to ${catalina.home}/conf/
  • Edit ${catalina.home}/conf/fediz_config.xml and replace '9443' with '8443'.
  • Do a "mvn clean install" in ${fediz.home}/examples/simpleWebapp
  • Copy ${fediz.home}/examples/simpleWebapp/target/fedizhelloworld.war to ${catalina.home}/webapps.
c) Testing the service

To test the service navigate to:
  • https://localhost:8443/fedizhelloworld/  (this is not secured) 
  • https://localhost:8443/fedizhelloworld/secure/fedservlet
With the latter URL, the browser is redirected to the IDP (select realm "A") and is prompted for a username and password. Enter "alice/ecila" or "bob/bob" or "ted/det" to test the various roles that are associated with these username/password pairs.

Finally, you can see the metadata of the service via the standard URL:
  • https://localhost:8443/fedizhelloworld/FederationMetadata/2007-06/FederationMetadata.xml 
d) Obtaining a SAML 1.1 token via wreq

Let's assume that the Service Provider can only handle SAML 1.1 tokens. Fediz 1.1.1 supports this by allowing the service provider to configure a "request" parameter to send a WS-Trust RequestSecurityToken Element to the IdP containing a desired TokenType. To update the example above to obtain a SAML 1.1 token instead of a SAML 2.0 token do the following:
  • Update ${catalina.home}/conf/fediz_config.xml + add the following to the "protocol" section: <request type="String">&lt;RequestSecurityToken xmlns=&quot;http://docs.oasis-open.org/ws-sx/ws-trust/200512&quot;&gt;&lt;TokenType&gt;http://docs.oasis-open.org/wss/oasis-wss-saml-token-profile-1.1#SAMLV1.1&lt;/TokenType&gt;&lt;/RequestSecurityToken&gt;</request>
Now simply follow the same steps as before in accessing 'fedizhelloworld/secure/fedservlet' in a browser. You will see that the Bootstrap token that appears on the final screen is now a SAML 1.1 token.
Categories: Colm O hEigeartaigh

Apache CXF Authentication and Authorization test-cases II

Colm O hEigeartaigh - Thu, 05/29/2014 - 15:19
In a previous blog post, I covered a number of Apache CXF-based authentication and authorization testcases I uploaded to github. The testcases showed how to authenticate and authorize a SOAP request containing either a SOAP UsernameToken or HTTP Basic Authentication. The options for authentication/authorization backends included Apache DS (ldap), Apache Syncope, Apache Shiro, and Spring Security. In this post, I will cover a number of more advanced authentication and authorization testcases for JAX-WS services using Apache CXF.

The new projects are as follows:
  • cxf-x509: This shows how to use X.509 tokens for authentication and authorization. The service has a TransportBinding policy with an EndorsingSupportingToken X509Token policy. The roles of the authenticated client are mocked by a WSS4J Validator for this demo, but could be retrieved from (e.g) an ldap backend in a real-world demo.
  • cxf-sts: The service in this demo has a TransportBinding policy with an EndorsingSupportingToken IssuedToken policy, requiring a SAML 2.0 token in a client request. The client obtains a SAML token from the CXF SecurityTokenService (STS) and includes it in the service request (also signing the request using the private key which corresponds to the certificate in the SAML token). An Authorization test is also available which uses Claims in the policy to tell the STS to add the roles of the client in the SAML token, which are then used for RBAC on the service side.
  • cxf-sts-xacml: Similar to the cxf-sts demo, this testcase requires a SAML 2.0 token from the STS with the roles of the client embedded in the token. The service is then configured to create a XACML request and dispatch it to a Policy Decision Point (PDP) for authorization. The service endpoint then enforces the authorization decision of the PDP. This demo ships with a mocked PDP implementation. For an enterprise-grade PDP which works with CXF, please see Talend ESB.
  • cxf-kerberos: The service in this demo requires a Kerberos token over TLS. A Kerberos KDC is started as part of the demo, and a CXF JAX-WS client obtains a token and sends it across to the service for authentication. Spnego is also demonstrated as part of this test-case.
These demos build on the first set of demos, which gave different ways to authentication/authorize Username+Password based requests. They show how to authenticate requests using X.509 Tokens, Kerberos tokens and SAML tokens, as well as how to retrieve SAML tokens from an STS, and how to authorize requests using XACML. Please feel free to download + play around with the testcases.
Categories: Colm O hEigeartaigh

Apache CXF 3.0.0 released

Colm O hEigeartaigh - Wed, 05/21/2014 - 22:48
Apache CXF 3.0.0 has been released. CXF 3.0.0 picks up Apache Santuario 2.0.0 and WSS4J 2.0.0, and hence all of the new streaming XML/WS-Security functionality available in those releases. Please see the CXF 3.0.0 migration guide for more details about upgrading from an older release. I've also updated the CXF Authentication and Authorization tests in my github repo to use CXF 3.0.0.
Categories: Colm O hEigeartaigh

Apache WSS4J 2.0.0 released

Colm O hEigeartaigh - Wed, 05/07/2014 - 11:14
Apache WSS4J 2.0.0 has been released. This major new release features a new StAX-based implementation of WS-Security, as well as a whole host of other changes and features. I've collected a lot of the information on this blog and created a User Guide for WSS4J as a result, so this is a good place to start to learn about the project and the new features of the release.
Categories: Colm O hEigeartaigh

Apache Santuario - XML Security for Java 2.0.0

Colm O hEigeartaigh - Tue, 05/06/2014 - 15:41
Apache Santuario - XML Security for Java 2.0.0 has been released, after many months of development work. The main new feature of this release is a new StAX-based API for XML Signature and Encryption. Please see the following page for an overview of this functionality, with some links back to this blog containing configuration and samples. In addition to this new API, the other changes of note in this release are that the JSR-105 API has been removed, and instead will be picked up from the JDK. This simplifies deployment in OSGi containers. In addition, the minimum supported JDK version for this release is now Java 6.
Categories: Colm O hEigeartaigh

Apache WSS4J 2.0.0 - part VIII

Colm O hEigeartaigh - Tue, 05/06/2014 - 12:39
This is the eight and final article on Apache WSS4J 2.0.0. In the previous post, I discussed how to use the new streaming WS-Security functionality of Apache WSS4J 2.0.0 via the "action" based configuration approach. In this post, I will show how the new streaming functionality can be used with Apache CXF when using WS-SecurityPolicy. I will also discuss the limitations of the streaming code compared to the older DOM implementation of WS-Security.

1) Streaming WS-Security functionality via WS-SecurityPolicy

As stated in the previous article, WSS4J must be used with a SOAP stack such as Apache CXF, Axis, etc. to secure messages via WS-Security. Both CXF and Axis support WS-SecurityPolicy, which means that you can use a standard WS-Policy expression to configure the security requirements for your service, and CXF/Axis/etc. will parse the policy and set up WSS4J appropriately. The user only has to configure things like usernames, keystores, etc. Apache CXF 3.0.0 supports using the new streaming functionality of Apache WSS4J 2.0.0, via the new boolean JAX-WS property:
  • SecurityConstants.ENABLE_STREAMING_SECURITY ("ws-security.enable.streaming") - whether to use the new streaming WS-Security implementation with WS-SecurityPolicy, or the older DOM implementation. The default is "false".
So switching to use the new streaming implementation is as simple as setting a boolean configuration property on your CXF client/endpoint.

2) Limitations of the streaming WS-Security implementation in WSS4J 2.0.0

WS-Security (and WS-SecurityPolicy) covers a wide area in terms of requirements and features. The new streaming implementation in WSS4J 2.0.0 meets 90%+ of the most common use-cases. However, some things are not implemented, and the user will have to use the DOM implementation instead for these requirements. The limitations are:
  • XPath evaluation is not supported apart from certain simple expressions. XPath evaluations are used with WS-SecurityPolicy RequiredElements, SignedElements, (Content)EncryptedElements. XPath expressions that point directly to the element are supported, e.g. /soap:Envelope/soap:Header/wsa:To.
  • WS-SecurityPolicy "Strict" Layout validation is not enforced. This includes enforcing whether a Timestamp is first or last.
  • A SymmetricBinding policy with a ProtectTokens assertion is not supported.
  • The combination of EncryptBeforeSigning + EncryptSignature policies are not supported.
  • Deriving keys from Username Tokens (Endorsing Username Tokens) are not supported.
  • Endorsing tokens don't work with Symmetric + Asymmetric binding on the client side, unless the endorsing token is a SAML or IssuedToken.
  • Derived Endorsing Tokens are not supported on the client side.


Categories: Colm O hEigeartaigh

Apache WSS4J 2.0.0 - part VII

Colm O hEigeartaigh - Thu, 05/01/2014 - 12:16
This is the seventh in a series of articles on Apache WSS4J 2.0.0. Up to now I've discussed the new features and changes for the older DOM implementation of WS-Security in WSS4J 2.0.0. This post will look at using the new streaming WS-Security functionality available in WSS4J 2.0.0, when security is configured via the "action"-based approach (as opposed to using WS-SecurityPolicy).

The WSS4J user guide has an article about the different ways to use WSS4J. The "action" based approach is when you specify a series of security actions to be performed on the outbound side. On the inbound side, the actions are used to verify that the security requirements you were expecting in the message were enforced. Aside from specifying actions, you also need to configure WSS4J with keystore information, usernames, CallbackHandler implementations to retrieve passwords, algorithms to use, etc. See the WSS4J user guide for more information on the configuration options for WSS4J.

1) Streaming WS-Security functionality via the "action" approach

WSS4J must be used with a SOAP stack such as Apache CXF, Axis, etc. to secure messages via WS-Security. For example, Apache CXF has two interceptors WSS4JOutInterceptor and WSS4JInInterceptor that use WSS4J under the hood to apply WS-Security to an outbound + inbound message. Both classes take a Map<String, Object> constructor argument, which is the set of WSS4J configuration options. So how do we switch over to use the new streaming WS-Security implementation in CXF 3.0.0? Easy, simply change the interceptors to WSS4JStaxOutInterceptor and WSS4JStaxInInterceptor! Both of these interceptors also take the same Map<String, Object> as constructor arguments.

2) Configuration differences between the DOM + StAX implementations

The new StAX functionality in WSS4J was designed to be configured in an almost identical way to the DOM code. For the vast majority of use-cases, the configuration will be exactly the same, meaning that you only need to change the interceptor names to pick up the new functionality. Both stacks share the same ConfigurationConstants class. The only substantive difference is that the StAX implementation supports two actions, that the DOM implementation does not:
  • SIGNATURE_WITH_KERBEROS_TOKEN - Perform a Signature action with a kerberos token.
  • ENCRYPT_WITH_KERBEROS_TOKEN - Perform a Encryption action with a kerberos token.
In conclusion, a user of Apache CXF should find migrating to use the new streaming implementation of WSS4J 2.0.0 as simple as changing the interceptor names (with the caveat that WSS4J 2.0.0 requires some configuration changes for both the DOM + StAX implementations, as covered in previous blog entries).
Categories: Colm O hEigeartaigh

New security advisories for Apache CXF

Colm O hEigeartaigh - Wed, 04/30/2014 - 19:10
Four new security advisories have been disclosed for Apache CXF. They are:
  • CVE-2014-0109: HTML content posted to SOAP endpoint could cause OOM errors
  • CVE-2014-0110: Large invalid content could cause temporary space to fill
  • CVE-2014-0034: The SecurityTokenService accepts certain invalid SAML Tokens as valid
  • CVE-2014-0035: UsernameTokens are sent in plaintext with a Symmetric EncryptBeforeSigning policy
Please see the security advisories page of Apache CXF for more information. Users are strongly encouraged to upgrade to the latest releases (2.6.14 and 2.7.11).
Categories: Colm O hEigeartaigh

XML Security improvements for JAX-RS in Apache CXF 3.0.0

Colm O hEigeartaigh - Tue, 04/29/2014 - 12:20
Recently on this blog, I've covered the new streaming XML Security functionality that will be available in Apache Santuario - XML Security for Java 2.0.0. For more information about why to use the new streaming implementation, as well as how to use it, please review the following - XML Signature is covered here,  XML Encryption is covered here, and some memory benchmarks are presented here. This article will cover using the new streaming XML Security implementation with JAX-RS messages in Apache CXF 3.0.0.

Apache CXF has the ability to secure JAX-RS clients and service XML requests with both XML Signature and Encryption, please see the CXF documentation for more information. Given that a new StAX-based XML Security implementation was available via Apache Santuario - XML Security for Java 2.0.0, it was natural to port this to CXF to be used by JAX-RS clients and endpoints. To show how to use the new functionality (as well as the older DOM-based XML Security functionality), I've created a new cxf-jaxrs-xmlsecurity project in github.

1) XML Signature test-cases

The following tests show how to use XML Signature with JAX-RS clients and endpoints:
The clients are configured in code, and the service endpoints are configured in spring. The service configuration for the streaming case is here
 2) XML Encryption test-cases

The following tests show how to use XML Encryption with JAX-RS clients and endpoints:
The clients are configured in code, and the service endpoints are configured in spring. The service configuration for the streaming case is here

3) Configuration

The streaming XML Security implementation is configured in a very similar way to the DOM implementation. In the tests above, the same configuration parameters (usernames, keys, callbackhandler, etc.) are passed as properties for both implementations. One difference is that the streaming implementation has a single unified interceptor for both XML Signature and XML Encryption, whereas the DOM code has separate interceptors for both cases.

For the outbound case, the interceptor is XmlSecOutInterceptor. This interceptor
has the following properties that can be configured:
  • EncryptionProperties encryptionProperties - An EncryptionProperties Object to use to configure algorithms for encryption.
  • SignatureProperties sigProps - A SignatureProperties Object to use to configure algorithms for signature.
  • boolean encryptSymmetricKey - Whether to encrypt the symmetric key or not in an EncryptedKey. The default is true.
  • SecretKey symmetricKey - A symmetric key to use. If not specified, it is generated randomly.
  • boolean signRequest - Whether to sign the request or not. Default is false.
  • boolean encryptRequest - Whether to encrypt the request or not. Default is false.
  • List<QName> elementsToSign - The QNames of Elements in request to sign. If not specified the entire request is signed.
  • List<QName> elementsToEncrypt - The QNames of Elements in request to encrypt. If not specified the entire request is encrypted.
  • boolean keyInfoMustBeAvailable - Whether to add a KeyInfo structure or not to the signature/encryption. The default is true.
The inbound interceptor is XmlSecInInterceptor. This has the following properties that can be configured:
  • EncryptionProperties encryptionProperties - An EncryptionProperties Object to use to configure algorithms for encryption.
  • SignatureProperties sigProps - A SignatureProperties Object to use to configure algorithms for signature. 
  • String decryptionAlias - The alias to use to retrieve a private key from the keystore to decrypt the request. If not specified it falls back to the default alias in the Crypto properties file (if specified).
  • String signatureVerificationAlias - The alias to use to retrieve a certificate/public key from the keystore to verify the Signature, if the Signature does not contain a KeyInfo with a complete certificate/key.
  • boolean requireSignature - Whether the request must be signed. The default is false.
  • boolean requireEncryption - Whether the request must be encrypted. The default is false.
4) Some observations
The new streaming JAX-RS XML Security implementation is quite similar in terms of functionality and behaviour to the older DOM implementation. However there are a few differences to note:
  • The DOM-based XML Signature implementation supports Enveloped, Enveloping and Detached "styles". The StAX implementation only supports Enveloped.
  • The decryption alias must be supplied for the StAX case (or a default alias in the Crypto properties file). The DOM code takes the EncryptedKey and checks for a matching private key in the Crypto properties file. The StAX code expects to be supplied with the matching private key.
  • The XmlSecInInterceptor has booleans "requireSignature" and "requireEncryption" which should be set if you want to enforce that a message should be signed and/or encrypted. However, there are some scenarios where the internal interceptor that enforces these requirements may run before security processing has finished. If you are seeing exceptions along these lines, then disable the boolean values, but it is up to you then to retrieve the stored security values and match them against the security requirements.
Categories: Colm O hEigeartaigh

Apache Santuario - XML Security for Java 2.0.0 - part III

Colm O hEigeartaigh - Fri, 04/25/2014 - 12:31
In the previous couple of posts, I've introduced the new streaming functionality of Apache Santuario - XML Security for Java 2.0.0. The first post focused on XML Signature and the second post focused on XML Encryption. This post will discuss the performance of the new streaming approach. In particular, we will focus on the memory consumption of the DOM vs StAX implementations as the size of the XML tree increases. Both implementations are roughly equivalent in terms of timing, however as we will see there is a big different in terms of memory usage.

1) Encryption

Here is a graph that shows the memory consumption of the StAX versus DOM implementations for encryption, as the size of the XML tree grows.



2) Decryption

Here is a graph that shows the memory consumption of the StAX versus DOM implementations for decryption, as the size of the XML tree grows.


3) Signature Creation

Here is a graph that shows the memory consumption of the StAX versus DOM implementations for signature creation, as the size of the XML tree grows. This is the only case where the memory consumption of the streaming code does not remain relatively flat, as some caching is involved in the signature creation case. However, the memory consumption is still substantially less than for the DOM code.


4) Signature Verification

Here is a graph that shows the memory consumption of the StAX versus DOM implementations for signature verification, as the size of the XML tree grows.


5) Conclusion

The new streaming implementation in Apache Santuario - XML Security for Java uses far less memory for large XML trees than the current DOM implementation for XML Encryption and XML Signature verification. It also uses substantially less memory for large XML trees for XML Signature creation. If you are working with large XML trees then you should experiment with the new functionality to see if it improves performance.

Categories: Colm O hEigeartaigh

Apache Santuario - XML Security for Java 2.0.0 - part II

Colm O hEigeartaigh - Wed, 04/23/2014 - 13:26
In the previous blog post, I covered the new StAX-based (streaming) XML Signature functionality coming in Apache Santuario - XML Security for Java 2.0.0. In this post, I will focus on the new streaming XML Encryption functionality that will also be available in this release.

1) XML Encryption test-cases

I have uploaded some test-cases to github to show how to use the new StAX-based API. The tests and setup mirror the XML Signature testcases that I covered in the previous blog post. There are currently three junit tests in this project:

2) Outbound StAX configuration

To see how to configure the new outbound StAX-based XML Encryption functionality, take a look at the "encryptUsingStax" method used by the tests. The streaming XML Security functionality is configured by populating a XMLSecurityProperties Object. You must typically call the following methods for XML Encryption:
  • properties.setAction(XMLSecurityConstants.Action) - an "Action" to perform, which for XML Encryption purposes is XMLSecurityConstants.ENCRYPT. 
  • properties.setEncryptionKey(Key) - The encrypting key. Typically a SecretKey instance.
  • properties.setEncryptionSymAlgorithm(String) - Symmetric encryption Algorithm to use. The default is AES 256.
  • properties.addEncryptionPart(SecurePart) - Add a SecurePart to encrypt, e.g. encrypt a given QName. 
  • properties.setEncryptionTransportKey(Key) - The key to use to encrypt the secret key (if desired). Either a SecretKey or PublicKey instance.
  • properties.setEncryptionKeyTransportAlgorithm(String) - The encryption key transport algorithm to use, to encrypt the secret key (if desired). Default is RSA OAEP.
  • properties.setEncryptionKeyIdentifier(SecurityTokenConstants.KeyIdentifier) - How to reference the encrypting key/cert. The default is SecurityTokenConstants.KeyIdentifier_IssuerSerial.  
The valid Encryption KeyIdentifier types are:
  • SecurityTokenConstants.KeyIdentifier_KeyValue
  • SecurityTokenConstants.KeyIdentifier_KeyName
  • SecurityTokenConstants.KeyIdentifier_IssuerSerial
  • SecurityTokenConstants.KeyIdentifier_SkiKeyIdentifier
  • SecurityTokenConstants.KeyIdentifier_X509KeyIdentifier
  • SecurityTokenConstants.KeyIdentifier_X509SubjectName
  • SecurityTokenConstants.KeyIdentifier_NoKeyInfo
3) Inbound StAX configuration

To see how to configure the new inbound StAX-based XML Encryption functionality, take a look at the "decryptUsingStAX" method used by the tests. As with encryption creation, it is necessary to create a XMLSecurityProperties Object, and to tell it what "Action" to perform. In addition you must call the following method:
  • properties.setDecryptionKey(Key) - a key to use to decrypt the request.
In addition, it is possible to pass a SecurityEventListener to record what security events were performed (see TestSecurityEventListener used in the tests). This allows the user to check what algorithms were used, what was encrypted etc.
Categories: Colm O hEigeartaigh

Apache Santuario - XML Security for Java 2.0.0

Colm O hEigeartaigh - Tue, 03/18/2014 - 18:05
In recent posts I have described some of the new features of the forthcoming Apache WSS4J 2.0.0 release. In particular, I focused on the changes and improvements to the existing "in-memory" (DOM-based) WS-Security implementation. However, the biggest new feature of WSS4J 2.0.0 will be a new streaming (StAX-based) WS-Security stack. In the next couple of posts, we will examine the core streaming XML Security functionality that will be available in the Apache Santuario - XML Security for Java 2.0.0 release.

The existing Apache Santuario - XML Security for Java implementation is DOM-based. What this essentially means is that the complete XML Document must be read into memory before being signed or verified. For large XML Documents this carries a corresponding performance penalty. In addition, it means that XML Signature is not feasible for very large documents. In contrast, the StAX API uses a streaming approach, resulting in very low memory usage.

The streaming XML/WS-Security functionality is split between the Apache Santuario and WSS4J projects. The Apache Santuario project contains the core streaming capabilities for XML Signature and Encryption. The Apache WSS4J project builds on this functionality to deliver a streaming WS-Security stack. The entire streaming security functionality is the work of Marc Giger, who donated his SWSSF project to Apache. Marc has done an outstanding job to implement this technically difficult task, and also to integrate the functionality into existing Apache projects. If you wish to experiment with the new functionality, it is available via the 2.0.0-rc1 release.

1) XML Signature test-cases

In this post we will focus on XML Signature only. I have uploaded some test-cases to github to show how to use the new StAX-based API. There are currently three junit tests in this project:
2) Outbound StAX configuration

To see how to configure the new outbound StAX-based XML Signature functionality, take a look at the "signUsingStAX" method used by the tests. The streaming XML Security functionality is configured by populating a XMLSecurityProperties Object. You must typically call the following methods:
  • properties.setAction(XMLSecurityConstants.Action) - an "Action" to perform, which for XML Signature purposes is XMLSecurityConstants.SIGNATURE. 
  • properties.setSignatureKey(Key) - The signing key. Can be a PrivateKey or SecretKey.
  • properties.setSigningCerts(X509Certificate[]) - The signing certs. May be inserted into the Signature KeyInfo depending on the Signature KeyIdentifier.
  • properties.addSignaturePart(SecurePart) - Add a SecurePart to sign, e.g. sign a given QName. You can also specify a digest method or transform algorithm here. You can also sign the entire request via SecurePart.setSecureEntireRequest(boolean).
  • properties.setSignatureAlgorithm(String) - Signature Algorithm to use. The default depends on the signing key.
  • properties.setSignatureDigestAlgorithm(String) - Signature Digest Algorithm to use. The default is the URI for SHA-1.
  • properties.setSignatureCanonicalizationAlgorithm(String) - The canonicalization algorithm to use. The default is XMLSecurityConstants.NS_C14N_EXCL_OMIT_COMMENTS.
  • properties.setSignatureKeyIdentifier(SecurityTokenConstants.KeyIdentifier) - How to reference the signing key/cert. The default is SecurityTokenConstants.KeyIdentifier_IssuerSerial.  
The valid Signature KeyIdentifier types are:
  • SecurityTokenConstants.KeyIdentifier_KeyValue
  • SecurityTokenConstants.KeyIdentifier_KeyName
  • SecurityTokenConstants.KeyIdentifier_IssuerSerial
  • SecurityTokenConstants.KeyIdentifier_SkiKeyIdentifier
  • SecurityTokenConstants.KeyIdentifier_X509KeyIdentifier
  • SecurityTokenConstants.KeyIdentifier_X509SubjectName
  • SecurityTokenConstants.KeyIdentifier_NoKeyInfo
By default, the Signature Element is attached as the first child of the root document.

3) Inbound StAX configuration

To see how to configure the new inbound StAX-based XML Signature functionality, take a look at the "verifyUsingStAX" method used by the tests. As with signature creation, it is necessary to create a XMLSecurityProperties Object, and to tell it what "Action" to perform. In addition you must call the following method, unless the complete signing key is contained in the Signature KeyInfo:
  • properties.setSignatureVerificationKey(Key) - a key to use to verify the Signature.
In addition, it is possible to pass a SecurityEventListener to record what security events were performed (see TestSecurityEventListener used in the tests). This allows the user to check what keys were used for signature verification, what algorithms were used, what was signed etc. See the verifyUsingStAX method as above for some simple code to check the signing key and the elements that were signed.

Categories: Colm O hEigeartaigh

Apache CXF Authentication and Authorization test-cases

Colm O hEigeartaigh - Wed, 03/12/2014 - 17:18
I've recently uploaded some test-cases to github that show different ways to authenticate and authorize a web services invocation using Apache CXF. Each project has the same two simple use-cases:
  • A JAX-WS request where the service requires a WS-Security UsernameToken over TLS.
  • A JAX-WS request where the service requires HTTP Basic Auth over TLS.
Each project has an "AuthenticationTest" that just illustrates some tests (including negative tests) for authentication, and then an "AuthorizationTest" that relies on authorizing the client based on roles that are retrieved as part of the authentication process somehow. The projects are as follows:
  • cxf-ldap: This project uses JAAS to authenticate a user via LDAP to a Apache Directory backend. The roles are also retrieved for the AuthorizationTest.
  • cxf-shiro: This project uses Apache Shiro for authentication and authorization.
  • cxf-spring-security: This project uses Spring Security for authentication and authorization.
  • cxf-syncope: This project uses the REST API of Apache Syncope for authenticating and authorizating users.
Feel free to download and play around with the projects.
Categories: Colm O hEigeartaigh

Apache WSS4J 2.0.0 - part VI

Colm O hEigeartaigh - Mon, 02/17/2014 - 17:07
This is the sixth of a series of articles on the new features and changes that will be delivered in Apache WSS4J 2.0.0. The fifth article looked at support for signing and encrypting message attachments via the SOAP with Attachments (SWA) Profile 1.1 specification, as well as the associated WS-SecurityPolicy expressions to sign and encrypt attachments. This post looks at the WS-SecurityPolicy model in WSS4J 2.0.0 and how it is used by the streaming code to perform real-time policy validation of an incoming message.

1) WS-SecurityPolicy model in WSS4J 2.0.0

The user of a web services stack such as Apache CXF or Apache Axis can use
WS-SecurityPolicy to define security requirements for service requests/responses. All that is required in addition to this is some user-specific configuration such as usernames, keystores, etc. However, WSS4J (1.6.x) had no awareness of whether WS-SecurityPolicy was used to define the security requirements or not. It was up to the web service stack in question to parse the security policy, build a model, and use the model to configure WSS4J appropriately. Then it was also up to the web services stack to go through the security results produced by WSS4J on processing a message, to see if the results conform to the policy or not.

WSS4J 2.0.0 includes a WS-SecurityPolicy model as part of the new module "wss4j-policy" module. This means that all web services stacks that rely on WSS4J to perform WS-Security no longer need their own model. Instead, they can register the Apache Neethi AssertionBuilder implementations in the WSS4J module to be able to handle WS-SecurityPolicy policies.

2) Real time streaming policy validation

The DOM-based WS-Security implementation in WSS4J 2.0.0 is still not WS-SecurityPolicy aware, in other words the web services stack must still parse the model to set up the configuration for WSS4J, and parse the results list to validate the results against the model. However, a significant new feature of WSS4J 2.0.0 is that the new streaming WS-Security implementation has the ability to perform "real-time" validation of a request against the set of applicable WS-SecurityPolicy policies. This means that bogus requests can be rejected quicker that the older DOM-based code, which may help to avoid DoS based scenarios. In the next few blog posts in this series, I'll be looking at the new streaming WS-Security implementation in more detail.
Categories: Colm O hEigeartaigh

Apache WSS4J 2.0.0 - part V

Colm O hEigeartaigh - Mon, 02/10/2014 - 17:36
This is the fifth of a series of articles on the new features and changes that will be delivered in Apache WSS4J 2.0.0. The fourth article looked at the ability to encrypt passwords in Crypto properties files. This post looks at support for signing and encrypting message attachments via the SOAP with Attachments (SWA) Profile 1.1 specification, as well as the associated WS-SecurityPolicy expressions to sign and encrypt attachments. Note that there is no support in WSS4J 1.6.x for signing or encrypting message attachments.

1) Configuring WSS4J to secure message attachments

There are two ways of using WSS4J, via an "action"-driven approach where WSS4J must be explicitly configured to perform all of the desired functionality, and via a WS-SecurityPolicy-based approach, where the web services stack sets up the WSS4J configuration internally based on a security policy. Let's look at how to secure message attachments for both of these approaches:

a) Securing message attachments via the "action" approach

With the "action" approach to using WSS4J, the user specifies the parts to sign or encrypt via the following configuration tags:
  • ConfigurationConstants.SIGNATURE_PARTS ("signatureParts")
  • ConfigurationConstants.ENCRYPTION_PARTS ("encryptionParts")
The value of these tags is a String in a special format that looks something like "{Content}{http://example.org/paymentv2}CreditCard". In this example, the element to be secured has the name "CreditCard" and namespace "http://example.org/paymentv2". "Content" only applies to Encryption, and means that the Content should be encrypted (as opposed to the full "Element").

In WSS4J 2.0.0, it is possible to sign/encrypt all of the attachments by specifying the following as part of signatureParts/encryptionParts: "{}cid:Attachments;". It is not possible to only sign/encrypt individual attachments, it is all or nothing. Here is an Apache CXF client configuration file with an example of this.

b) Securing message attachments via WS-SecurityPolicy

An easier way to use WSS4J is in conjunction with a web services stack such as Apache CXF and a WS-SecurityPolicy-based policy. It is possible to sign/encrypt all attachments via the policies:
  • <sp:SignedParts><sp:Attachments /></sp:SignedParts>
  • <sp:EncryptedParts><sp:Attachments /></sp:EncryptedParts>
In addition, the "<sp:Attachments>" policy for SignedParts only has two optional child policies called "sp13:ContentSignatureTransform" and "sp13:AttachmentCompleteSignatureTransform", which dictate whether the attachment headers are included or not in the Signature.

2) Supplying the message attachments to WSS4J

Part 1 above only covers how to configure WSS4J to sign/encrypt message attachments. It is also necessary to actually supply the message attachment streams to WSS4J. This is done in WSS4J via a CallbackHandler approach. An AttachmentRequestCallback Object is used to retrieve either a particular Attachment (on the receiving side), or all attachments (on the sending side). The user must implement a CallbackHandler that sets a list of Attachments matching this request on the Callback. Correspondingly, there is also a AttachmentResponseCallback, which represents the secured/processed Attachment.

The good news is that if you are using Apache CXF then all of this is taken care of automatically by a CallbackHandler that retrieves and sets CXF message attachments. Therefore if you are using CXF then you can sign/encrypt message attachments just by passing the configuration detailed in part 1 of this post. Finally, there are some system tests available in CXF that show how both the "action" and "policy" based approaches work to secure attachments. The test code is here and the resource/configuration files are here.
Categories: Colm O hEigeartaigh

Apache WSS4J 2.0.0 - part IV

Colm O hEigeartaigh - Wed, 02/05/2014 - 18:16
This is the fourth of a series of articles on the new features and changes that will be delivered in Apache WSS4J 2.0.0. The third article looked at some changes in the area of caching tokens to detect replay attacks. This post looks at a new feature of WSS4J 2.0.0, which is the ability to encrypt passwords in Crypto properties files.

1) Crypto properties

Apache WSS4J uses the Crypto interface to get keys and certificates for encryption/decryption and for signature creation/verification. WSS4J currently ships with three implementations:
  • Merlin: The standard implementation, based around two JDK keystores for key/cert retrieval, and trust verification.
  • CertificateStore: Holds an array of X509 Certificates. Can only be used for encryption and signature verification.
  • MerlinDevice: Based on Merlin, allows loading of keystores using a null InputStream - for example on a smart-card device.
Typically, a Crypto implementation is loaded and configured via a Crypto properties file. This tells WSS4J what Crypto implementation to load, as well as implementation-specific properties such as a keystore location, password, default alias to use, etc. A typical example of the contents of a Crypto properties file for Signature creation is as follows:

org.apache.wss4j.crypto.provider=org.apache.wss4j.common.crypto.Merlin
org.apache.wss4j.crypto.merlin.keystore.type=jks
org.apache.wss4j.crypto.merlin.keystore.password=security
org.apache.wss4j.crypto.merlin.keystore.alias=wss40
org.apache.wss4j.crypto.merlin.keystore.file=keys/wss40.jks

Note that in WSS4J 2.0.0 the "org.apache.ws.security.crypto" prefix used previously is now "org.apache.wss4j.crypto", however both prefixes are accepted by the code.

2) Encrypting passwords in a Crypto properties file

Note in the example above that the password used to load the keystore is in cleartext. One of the new features of Apache WSS4J 2.0.0 is the ability to instead store a (BASE-64 encoded) encrypted version of the keystore password in the Crypto properties file. A new PasswordEncryptor interface is defined to allow for the encryption/decryption of passwords. A default implementation is now provided based on Jasypt called JasyptPasswordEncryptor, which uses "PBEWithMD5AndTripleDES".

The way this works is as follows. The WSPasswordCallback class has an additional "usage" called WSPasswordCallback.PASSWORD_ENCRYPTOR_PASSWORD, which is used to return the password used with a PasswordEncryptor implementation to decrypt encrypted passwords stored in Crypto properties files. When WSS4J is loading a Crypto implementation via a properties file, and it encounters a password encrypted in the format "ENC(encoded encrypted password)", it queries a CallbackHandler for the (master) password to decrypt the encrypted password
using the WSPasswordCallback usage tag given above.

It is possible to pass a custom PasswordEncryptor implementation to WSS4J via the new configuration tag ConfigurationConstants.PASSWORD_ENCRYPTOR_INSTANCE ("passwordEncryptorInstance").
Categories: Colm O hEigeartaigh

Pages

Subscribe to Talend Community Coders aggregator - Colm O hEigeartaigh