Colm O hEigeartaigh

Subscribe to Colm O hEigeartaigh feed
Colm O hEigeartaigh
Updated: 2 min 41 sec ago

Apache Syncope tutorial - part I

Fri, 07/26/2013 - 14:26
Apache Syncope is a new open source Identity Management project at Apache. This is the first of a planned four-part set of tutorials on how to get Apache Syncope up and running, how to integrate it with various backends, and how to interact with its REST API.

In this tutorial we will explain how to create a new Apache Syncope project and how to deploy it to a container. We will also cover how to set up internal storage with a database, and how to install Connector bundles to communicate with backend resources. Please note that if you wish to download and play around with Apache Syncope, without going through the steps detailed in this tutorial to set it up for a standalone deployment, it is possible to download the 1.1.3 distribution and use an embedded Tomcat instance. In that case you can completely skip this tutorial and go straight to the next one.

1) Set up a database for Internal Storage

The first step in setting up a standalone deployment of Apache Syncope is to decide what database to use for Internal Storage. Apache Syncope persists internal storage to a database via Apache OpenJPA. In this article we will set up MySQL, but see here for more information on using PostgreSQL, Oracle, etc. Install MySQL in $SQL_HOME and create a new user for Apache Syncope. We will create a new user "syncope_user" with password "syncope_pass". Start MySQL and create a new Syncope database:
  • Start: sudo $SQL_HOME/bin/mysqld_safe --user=mysql
  • Log on: $SQL_HOME/bin/mysql -u syncope_user -p
  • Create a Syncope database: create database syncope; 
2) Set up a container to host Apache Syncope

The next step is to figure out in what container to deploy Syncope to. In this demo we will use Apache Tomcat, but see here for more information about installing Syncope in other containers. Install Apache Tomcat to $CATALINA_HOME. Now we will add a datasource for internal storage in Tomcat's 'conf/context.xml'. When Syncope does not find a datasource called 'jdbc/syncopeDataSource', it will connect to internal storage by instantiating a new connection per request, which carries a performance penalty. Add the following to 'conf/context.xml':

<Resource name="jdbc/syncopeDataSource" auth="Container"
    testWhileIdle="true" testOnBorrow="true" testOnReturn="true"
    validationQuery="SELECT 1" validationInterval="30000"
    maxActive="50" minIdle="2" maxWait="10000" initialSize="2"
    removeAbandonedTimeout="20000" removeAbandoned="true"
    logAbandoned="true" suspectTimeout="20000"
    timeBetweenEvictionRunsMillis="5000" minEvictableIdleTimeMillis="5000"
    username="syncope_user" password="syncope_pass"

Uncomment the "<Manager pathname="" />" configuration in context.xml as well. Next, download the JDBC driver jar for MySQL and put it in Tomcat's 'lib' directory. As we will be configuring a connector for a Derby resource in a future tutorial, also download the JDBC driver jar for Apache Derby and put it in Tomcat's 'lib' directory as well.

3) Create a new Apache Syncope project

To create a new Apache Syncope project, we must start with a Maven Archetype. For the purposes of this tutorial we will use Apache Syncope 1.1.3. Create a new directory to hold all of the project artifacts ($SYNCOPE_HOME). Create a new project in this directory as follows:

mvn archetype:generate

Enter values as requested for the 'groupId', 'artifactId', 'version', 'package' and 'secretKey'. A new Syncope project will be created in a directory corresponding to the value entered for 'artifactId'. Build the project by going into the newly created directory and typing "mvn clean package". To launch Syncope in "embedded" mode, go into the "console" subdirectory and type "mvn -Pembedded". This provides a quick way to start up Syncope with some test data and connectors pre-installed, along with a H2 instance for internal storage. However, instead of doing this we will set up a proper standalone deployment.

4) Install ConnId bundles

Apache Syncope uses bundles supplied by the ConnId project to communicate with backend resources. In part III of this series of tutorials we will cover importing users from a database backend, and part IV will cover using a directory backend. Therefore, we need two ConnId bundles to handle these scenarios. Create two new directories in $SYNCOPE_HOME, one called "bundles" to store the ConnId bundles, and another called "logs" to store logging information. Go to the ConnId download page, and download the relevant jars to the bundles directory you have created. It should have the following files:
  • org.connid.bundles.ldap-1.3.6.jar
  • org.connid.bundles.db.table-2.1.5.jar.
5) Configure the Apache Syncope project

After creating the Apache Syncope project, we need to configure it to use the ConnId bundles we have downloaded, the logging directory we have created, and the MySQL instance for internal storage.

Edit 'core/src/main/resources/' in your Syncope project, and replace the existing configuration with the following:


Edit 'core/src/main/webapp/WEB-INF/web.xml' and uncomment the "resource-ref" section (this is required as we are using a DataSource in Tomcat). If your Tomcat instance is starting on a port other than 8080, edit 'console/src/main/resources/' and change the port number.

6) Deploy Apache Syncope to Tomcat

Package everything up by executing the following command from the Syncope project:

mvn clean package${bundles.dir}${log.dir}

Deploy 'core/target/syncope.war' and 'console/target/syncope-console.war' to the Tomcat 7 container. Start Tomcat and point a browser at "localhost:8080/syncope-console", logging in as "admin/password". You should see the following:

At this point you should have successfully deployed Apache Syncope in the Apache Tomcat container, using MySQL as the internal storage. If this is not the case then consult the Tomcat logs, as well as the Syncope logs in the directory you have configured. In the next couple of tutorials we will look at importing data into our Syncope application from various backend resources.

Categories: Colm O hEigeartaigh

Denial of Service attacks on Apache CXF

Thu, 06/27/2013 - 16:52
A significant new paper has emerged called "A new Approach towards DoS Penetration Testing on Web Services" by Andreas Falkenberg of SEC Consult Deutschland GmbH, and Christian Mainka, Juraj Somorovsky and Joerg Schwenk of Ruhr-University Bochum. In this paper, the authors developed a suite of automated tests for various Denial of Service (DoS) attacks on Web Services, and ran them against different web service stacks. In this post I will describe the attacks that were successful on Apache CXF and how they were fixed.

The authors found that Apache CXF (prior to 2.7.4/ 2.6.7/ 2.5.10) was vulnerable (see CVE-2013-2160) to the following attacks:
  • Coercive Parsing Attack: The attacker sends a deeply nested XML document to the service.
  • Attribute Count Attack: The attacker sends a message with a (very) high attribute count.
  • Element Count Attack: The attacker sends a message with a (very) high number of non-nested elements.
  • DJBX31A Hash Collision: A specific hash collision attack.
The effects of these attacks can vary from causing high CPU usage, to causing the JVM to run out of memory. Clearly the latter is a critical vulnerability. Prior to CXF 2.7.4 / 2.6.7 / 2.5.10, a CXF service was vulnerable to these attacks "out of the box". However, it was possible to avoid some of the attacks using CXF's DepthRestrictingInterceptor. If this was added to the InInterceptor chain, then it was possible to control the stack depth + the number of elements in the request. However it was not possible to control the number of attributes with this interceptor, and it also came with a performance cost.

CXF uses Woodstox by default as the StAX XML Processor. It was decided that the best place to fix the vulnerabilities was at this level, both to offer protection to other stacks that use Woodstox, and also to remove the performance penalties associated with the DepthRestrictingInterceptor. From Woodstox 4.2.0, new functionality has been added to prevent Denial of Service attacks by restricting the size of XML. It uses the following defaults:
  • Maximum Attributes per Element: 1000.
  • Maximum Children per Element: (no effective bound).
  • Maximum Stack Depth: 1000.
  • Maximum Element Count: (no effective bound).
  • Maximum Number of Characters: (no effective bound).
These bounds are quite loose to preserve backwards compatibility. CXF 2.7.4 / 2.6.7 / 2.5.10 pick up Woodstox 4.2.0. Other parser implementations are defined as "insecure parsers" and are rejected by default from CXF 2.7.5 unless a System property is set. CXF restricts the Woodstox default values further:
  • Maximum Attributes per Element: 500.
  • Maximum Children per Element: 50000.
  • Maximum Stack Depth: 100.
CXF 2.7.4 / 2.6.7 / 2.5.10 are not vulnerable to any of the DoS attacks listed above due to these restrictions.

Categories: Colm O hEigeartaigh

Apache XML Security for Java 1.4.8 and 1.5.5 released

Tue, 06/25/2013 - 17:32
Two new versions of the Apache XML Security for Java project have been released and are available for download. These releases contain a fix for a critical security advisory CVE-2013-2172, which involves an XML Signature spoofing attack. Thanks to James Forshaw for reporting the vulnerability to the Apache Santuario project.
Categories: Colm O hEigeartaigh

Apache CXF 2.7.5 released

Wed, 05/22/2013 - 17:09
Apache CXF 2.7.5 has been released. The list of issues fixed is available here. The following security fixes of note have been made in this release:
  • The OpenSAML dependency has been upgraded from 2.5.1 to 2.5.3.
  • A change was made to the logic the STS uses to encrypt tokens that it issues. Previously it threw an exception if a key could not be found (at either service or at a more generic level) to use to encrypt the token. Now it only encrypts the token if a matching key can be found. This allows the ability to only encrypt tokens to specific "AppliesTo" endpoint addresses.
  • LDAP groups are now (better) supported as claims in the STS. See the following blog entry for more detail.
  • The CryptoCoverageChecker interceptor has been enhanced so that you can disable coverage checking for SOAP Faults. This is useful for testing/debugging if you want to figure out the root cause of a remote exception.
Categories: Colm O hEigeartaigh

Apache CXF 2.7.4 released

Thu, 04/25/2013 - 17:04
Apache CXF 2.7.4 (and 2.6.7 + 2.5.10) have been released. Users are strongly encouraged to upgrade to the latest versions, due to a critical security issue which must remain undisclosed for the moment. These latest releases pick up Apache Santuario 1.5.4 and Apache WSS4J 1.6.10. In addition to the fixes in these projects, CXF 2.7.4 contains a number of security fixes of interest.

1) WS-SecurityPolicy fixes

A large number of negative tests for WS-Security(Policy) were added to CXF to try to smoke out some remaining issues surrounding validating a request against a defined security policy. The following issues were fixed as a result:
  • Layout policies "LaxTimestampFirst" and "LaxTimestampLast" were not validated correctly.
  • X509Token "PKI" policies were not validated correctly.
  • The "OnlySignEntireHeadersAndBody" policy was not validated correctly.
  • The "ProtectTokens" policy was not validated correctly in conjunction with EndorsingSupportingTokens.
  • SAML Token versions weren't validated against policy versions in certain circumstances.
2) Populating the SecurityContext from a JAAS Subject from WSS4J

An additional improvement to the WS-Security layer in CXF is that the SecurityContext is now populated from a JAAS Subject from WSS4J, if one is available. For example, if you are using a custom UsernameTokenValidator with WSS4J to validate a received UsernameToken via JAAS, and are returning the Subject (as per WSS4J's JAASUsernameTokenValidator), then CXF will attempt to extract roles from the Subject and populate the SecurityContext accordingly. The advantage of this is that a user can check the standard SecurityContext methods (e.g. "isUserInRole") to perform authorization.

This is controlled by two JAX-WS properties (see the documentation for more information):
  • ws-security.role.classifier - The Subject Role Classifier to use.  If this value is not specified, then it tries to get roles using the DefaultSecurityContext in cxf-rt-core. Otherwise it uses this value in combination with the "ws-security.role.classifier.type" property to get the roles from the Subject.
  • ws-security.role.classifier.type - The Subject Role Classifier Type to use. Currently accepted values are "prefix" or "classname". Must be used in conjunction with the "ws-security.role.classifier". The default value is "prefix".
3) STS fixes

The SecurityTokenService (STS) fixes contained in this release are:
  • The STS Client was not always sending an "AppliesTo" address in a request to the STS, depending on how the STS Client was deployed.
  • The STS Client was always using the "old" WS-Policy namespace for "AppliesTo", instead of getting the namespace from the policy.
  • The STS now supports processing Claims in a request that are retrieved from a security policy as "IssuedToken/Claims". Previously, it would only issue claims that were contained in a "RequestSecurityTokenTemplate" policy. 
4) CVE-2012-5572

Finally, a note on security advisory CVE-2012-5572 was added to the CXF security advisories page. This attack exploits the fact that Apache CXF will attempt to decrypt arbitrary ciphertexts, without first checking to see if the algorithm corresponds to the given encryption algorithm defined by the WS-SecurityPolicy AlgorithmSuite definition. This can be exploited by chosen ciphertext attacks to retrieve the plaintext. Please note that this issue has been fixed since CXF 2.5.7, 2.6.4, and 2.7.1.

    Categories: Colm O hEigeartaigh

    Apache Santuario 1.5.4 and Apache WSS4j 1.6.10 released

    Fri, 04/19/2013 - 17:37
    Two new bug-fix releases of note in Apache security products:

    Apache Santuario 1.5.4 has been released. Amongst the issues fixed is a thread-safety problem when secure validation is enabled, and a possible NPE due to ThreadLocal storage when an application is deployed in certain containers.

    Apache WSS4J 1.6.10 has also been released. The issues fixed are available here. A performance issue was fixed in the MemoryReplayCache, which is used to guard against replay attacks. An interop issue was fixed with older Axis 1.x stacks. UsernameTokens with no password elements have been explicitly disallowed by default (although this is configurable). Finally, "time-to-live" functionality has been added to disallow "stale" UsernameTokens (with older Created values).
    Categories: Colm O hEigeartaigh

    Signature and Encryption Key Identifiers in Apache WSS4J

    Thu, 03/14/2013 - 14:31
    The Apache WSS4J configuration allows you to specify how to reference a public key or certificate when signing or encrypting a SOAP message via the following configuration items:
    This blog entry will explain what values are valid for each of these configuration items, and will explain what each of these values means. Firstly, let's look at what these configuration items refer to.

    When creating a Signature you have the option of adding content to the Signature KeyInfo Element. This lets the recipient know what certificate/public key to use to verify the signature. Specifying a value for WSHandlerConstants.SIG_KEY_ID allows you to change how to refer to the key.

    When encrypting some part of the message, a session key is typically generated and used to encrypt the message part, which is then wrapped in an EncryptedData Element. This refers (typically via a Direct Reference) to a EncryptedKey Element in the security header, where the session key is encrypted using the public key of the recipient. Specifying a value for WSHandlerConstants.ENC_KEY_ID allows you to change how to refer to the public key of the recipient in the EncryptedKey KeyInfo element.

    The following valid values for these configuration items are:
    • IssuerSerial (default)
    • DirectReference
    • X509KeyIdentifier
    • Thumbprint
    • SKIKeyIdentifier
    • KeyValue (signature only)
    • EncryptedKeySHA1 (encryption only)
    1) IssuerSerial

    This (default) key identifier method means that the Issuer Name and Serial Number of a X.509 Certificate is included directly in the KeyInfo Element. For example:


    The certificate is not included in the message and so the recipient will have to have access to the certificate matching the given Issuer Name and Serial Number in a keystore.

    2) DirectReference

    This key identifier method is used when the X.509 Certificate is included in the message, unlike the IssuerSerial case above. The certificate is Base-64 encoded and included in the request via a BinarySecurityToken element, e.g.:

    <wsse:BinarySecurityToken EncodingType="...#Base64Binary"

    This Certificate is then referred to directly from the KeyInfo Element as follows:

            <wsse:Reference URI="#X509-..." ValueType="...#X509v3"/>

    3) X509KeyIdentifier 

    This key identifier method is similar to DirectReference, in that the certificate is included in the request. However, instead of referring to a certificate, the certificate is included directly in the KeyInfo element, e.g.:

            <wsse:KeyIdentifier EncodingType="...#Base64Binary"

    4) Thumbprint

    This Key Identifier method refers to the Certificate via a SHA-1 Thumbprint. The certificate may or may not be included in the request. For example:

            <wsse:KeyIdentifier EncodingType="...#Base64Binary"

    5) SKIKeyIdentifier

    This Key Identifier method refers to a Certificate via a Base-64 encoding of the Subject Key Identifier, e.g.:

            <wsse:KeyIdentifier EncodingType="...#Base64Binary"

    6) KeyValue

    This Key Identifier method only applies for Signatures. It includes the (RSA) PublicKey directly in the Signature KeyInfo Element as follows:


    7) EncryptedKeySHA1

    This Key Identifier method only applies for Encryption. Unlike the previous methods it refers to the way the EncryptedData references the EncryptedKey Element, rather than the way the EncryptedKey Element refers to the public key. For example:

        <wsse:KeyIdentifier EncodingType="...#Base64Binary"   

    Categories: Colm O hEigeartaigh

    Recent security advisories for Apache CXF

    Thu, 02/28/2013 - 23:46
    Apache CXF 2.7.3 (release notes), 2.6.6, and 2.5.9 have been released and are available for download. These releases contain fixes for a number of critical security issues, which I will describe below.

    1) CVE-2012-5633

    A security advisory has been issued in relation to a possible circumvention of WS-Security processing of an inbound request, due to the URIMappingInterceptor in CXF. This is a legacy interceptor (largely made redundant by JAX-RS) that allows some basic "rest style" access to a simple SOAP service. The vulnerability occurs when a simple SOAP service is secured with the WSS4JInInterceptor. WS-Security processing is completely by-passed in the case of a HTTP GET request, and so unauthenticated access to the service can be enabled by the URIMappingInterceptor.

    This is a critical vulnerability if you are using a WS-Security UsernameToken
    or a SOAP message signature via the WSS4JInInterceptor to authenticate users
    for a simple SOAP service. Please note that this advisory does not apply if
    you are using WS-SecurityPolicy to secure the service, as the relevant policies
    will not be asserted. Also note that this attack is only applicable to
    relatively simple services that can be mapped to a URI via the URIMappingInterceptor.

    Although this issue is fixed in CXF 2.5.8, 2.6.5 and 2.7.2, due to a separate
    security vulnerability (CVE-2013-0239), CXF users should upgrade to either 2.5.9, 2.6.6, or 2.7.3.

    2) CVE-2013-0239

    A security advisory has been issued in relation to an authentication bypass involving a UsernameToken WS-SecurityPolicy requirement. If a UsernameToken element is sent with no password child element, then authentication is bypassed by default. This is due to the use-case of supporting deriving keys from a UsernameToken, where a password element would not be sent in the token.

    The vulnerability does not apply in any of the following circumstances:
    • You are using a custom UsernameTokenValidator which does not allow the 'verifyUnknownPassword' use-case, or that otherwise insists that a password must be present in the token (such as the 'JAASUsernameTokenValidator' in WSS4J).
    • You are using a 'sp:HashPassword' policy that requires a hashed password to be present in the token.
    • You are using the older style of configuring WS-Security without using WS-SecurityPolicy.
    If you are relying on WS-SecurityPolicy enabled plaintext UsernameTokens to
    authenticate users, and if neither points a) nor b) apply, then you must
    upgrade to either CXF 2.5.9, 2.6.6 or 2.7.3, or else configure a custom
    UsernameTokenValidator implementation to insist that a password element must
    be present.

    3) Note on CVE-2011-2487

    A security advisory 'note' was also published to the CXF Security Advisories page, giving details on an attack against XML Encryption that affects users of older versions of CXF (prior to 2.5.3 and 2.4.7). It carries the following recommendation:
    It is recommended that the use of the RSA v1.5 key transport algorithm be discontinued. Instead the RSA-OAEP key transport algorithm should be used. This algorithm is used by default from WSS4J 1.6.8 onwards. If you are using WS-SecurityPolicy, then make sure not to use the AlgorithmSuite policies ending in "Rsa15.
    Categories: Colm O hEigeartaigh

    WS-Federation support in Apache CXF

    Sat, 02/23/2013 - 15:39
    Apache CXF is a leading web services stack with excellent support for a long list of security protocols such as WS-Security, OAuth, etc. A recent addition to this list is support for WS-Federation via the Apache CXF Fediz subproject. In this post, we will introduce Fediz and illustrate how to secure a web application with Fediz via an example.

    1) Introducing Apache CXF Fediz

    The Apache CXF Fediz subproject provides an easy way to secure your web applications via the WS-Federation Passive Requestor Profile. A good place to start in understanding this profile is to look at the Fediz architecture page. A typical scenario is that a client browser will attempt to access a web application secured with a Fediz plugin. Fediz will redirect the brower to an Identity Provider (IdP) for authentication, if no token/cookie is present in the request. In this way, authentication is externalized from the web application to a third party IdP.

    Fediz ships with an IdP component, but naturally the Fediz container plugin is also tested with other implementations. The IdP prompts the user for her credentials, and authenticates them via a Security Token Service (STS). The IdP requests that the STS issues a signed SAML Token on successful authentication. The IdP is configured to request that the STS inserts certain "Claim" attributes in the SAML Token, where the specific "Claim" types are configured per-realm. The client brower is then redirected back to the application server with the inclusion of the SAML Token.

    The Fediz plugin parses the received SAML Token. Authentication is established via the trust verification of the signature on the token. Role-based Access Control (RBAC) is supported by configuring the plugin with a "roleURI" attribute (which should correspond to the standard Claims URI for a role). The corresponding attribute values are extracted from the SAML Token and stored as the role(s) of the user. The actual security enforcement is delegated to the underlying container / application server. The containers that are (planned to be) supported are:
    • Apache Tomcat - See here.
    • Jetty - See here, available in the forthcoming 1.1 release.
    • Spring - See here, available in the forthcoming 1.1 release.
    • JBoss - Planned for the forthcoming 1.1 release. 
    An important point to note is that the Fediz container plugin is actually protocol-agnostic. WS-Federation is the only protocol supported to date, but support for the SAML Web SSO Profile may be added at a later date. For more detailed information on Fediz you should refer to the documentation, and also to the excellent series of blog articles by Oliver Wulff, who is the main developer on Fediz.

    2) Fediz example

    Download the latest Apache CXF Fediz release (currently 1.0.3) 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/ 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/tomcat-idp.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="tomcat-idp.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/STSService?wsdl'

    b) Deploying the service

    To deploy the service to Tomcat:
    • Copy ${fediz.home}/examples/samplekeys/tomcat-rp.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 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
    Categories: Colm O hEigeartaigh

    Recent security enhancements in Apache CXF 2.7.x

    Thu, 01/24/2013 - 20:17
    In this post, I will cover some new security features and enhancements that are contained in Apache CXF 2.7.2 (release notes), as well as the previous 2.7.1 release (release notes).

    1) STS Enhancements
    • The STS ClaimsManager used to call all ClaimsHandler implementations for processing. Now it only calls the implementations that support the requested claim (CXF-4461).
    • New functionality was added to the STS to support processing 'primary' and 'secondary' claims, and to merge claims with the same dialects (CXF-4664).
    • It is now possible for the STSClient to send a 'Claims' Element to the STS via a CallbackHandler (CXF-4638).
    • You can now configure signature + encryption Crypto objects in the STS via a URL or properties object, as per the runtime (CXF-4705).
    2) SAML Enhancements
    • SAML SubjectConfirmation requirements are now enforced for the non-policy case (CXF-4655).
    • The JAX-RS SAML interceptors have been enhanced to allow sending an existing SAML Token, rather than always creating one (CXF-4639).
    3) XACML Enhancements

    A new 'cxf-rt-security' module was introduced in CXF 2.7.1, for security functionality that is common to several of the runtime modules (WS-Security, RS-Security, etc.). For now this module contains some new security functionality based around XACML:
    • It contains some helper classes to construct XACML Request statements using OpenSAML for the XACML 2.0 core specification (see here), as well as the SAML Profile of XACML 2.0 (and here).
    • It contains an interface to create an XACML request given a Principal, list of roles and a CXF Message object, as well as a default implementation. This implementation follows the SAML 2.0 profile of XACML 2.0. The principal name is inserted as the Subject ID, and the list of roles associated with that principal are inserted as Subject roles.  The action to send defaults to "execute". The resource is the WSDL Operation for a SOAP service, and the request URI for a REST service. The current DateTime is also sent in an Environment.
    • An abstract interceptor is provided that wraps the XACML request creation functionality given above. It can perform an XACML authorization request to a remote PDP, and make an authorization decision based on the response. It takes the principal and roles from the CXF SecurityContext, and uses the XACMLRequestBuilder to construct an XACML Request statement.
    Categories: Colm O hEigeartaigh

    Apache WSS4J 1.6.9 released

    Mon, 01/07/2013 - 12:58
    Apache WSS4J 1.6.9 has been released. This release contains a single (critical) fix for a bug which prevented WSS4J 1.6.8 from working correctly in an OSGi container.
    Categories: Colm O hEigeartaigh

    Apache WSS4J 1.6.8 released

    Mon, 12/10/2012 - 15:33
    Apache WSS4J 1.6.8 has been released. The list of issues fixed is available here. One of the most significant improvements is a fix for using WSS4J with XML Signature on Websphere. A new feature has also been added to WSS4J 1.6.8, namely the ability to define which algorithms are acceptable when processing an inbound request. This functionality has already been integrated into CXF and will be available in the 2.7.1, 2.6.4 and 2.5.7 releases. This essentially means that rather than check the algorithms against the relevant AlgorithmSuite used as part of WS-SecurityPolicy after WSS4J has finished processing the security header, the algorithms will be checked by WSS4J in real-time when processing the header.

    A new page has been added to the WSS4J website which describes 'security best practices' when using WSS4J. The points are summarised as follows:
    • Upgrade from WSS4J 1.5.x to WSS4J 1.6.x
    • Upgrade to the latest minor release as soon as possible
    • Use WS-SecurityPolicy to enforce security requirements
    • Use RSA-OAEP for the Key Transport Algorithm
    • Avoid using a cbc Symmetric Encryption Algorithm
    • Use Subject DN regular expressions with chain trust
    • Specify signature algorithm on receiving side

    Categories: Colm O hEigeartaigh

    Apache XML Security for Java 1.5.3 released

    Mon, 10/22/2012 - 15:57
    Apache XML Security for Java 1.5.3 has been released. This release features support for new XML Signature 1.1 KeyInfo extensions. It also fixes a number of bugs including a problem when message sizes are greater than 512 MB. The list of issues fixed is available at the Apache JIRA.
    Categories: Colm O hEigeartaigh

    XML Signature Wrapping attacks on Web Services

    Wed, 10/03/2012 - 18:17
    The previous blog post looked at SOAP Action spoofing attacks on Web Services and discussed a recent security advisory in this area in Apache CXF. This vulnerability was uncovered with the help of the WS-Attacker tool referenced here. This paper also covers a different type of attack on WS-Security enabled Web Services, namely XML Signature Wrapping attacks. The WS-Attacker tool also offers some functionality to test Web Service endpoints for vulnerability against these types of attacks. In this post we will look at how to protect against XML Signature Wrapping attacks in Apache CXF.

    1) XML Signature wrapping attacks

    It is possible to sign a portion of a SOAP Web Service request or response at the message level using XML Signature. The message contains a security header with a Signature Element, that references one or more message parts that have been signed. Typically, the message parts are referenced by an Id, and so to validate the signature the recipient must find the Element in the request that has the corresponding Id. An XML Signature wrapping attack essentially exploits the fact that the Signature Element does not convey any information as to where the referenced Element(s) is(are) in the Document tree.

    Consider a scenario where the SOAP Body of a request is signed by a signature placed in the security header of the request. The message recipient checks that the signature is correct and validates trust in the signing credential. Finally, the recipient checks to see that the required Element (in this case the SOAP Body) was actually signed, by comparing the wsu:Id of the SOAP Body to the Reference URI in the Signature.

    An XML Signature wrapping attack against this scenario could work as follows. A malicious (man-in-the-middle) user could take a valid request and copy the SOAP body and insert it as part of a header in the request. The malicious user then freely alters the SOAP Body, but preserves the same wsu:Id. The message recipient must search for the Reference URI as part of the signature validation process, and hits the copied SOAP Body Element first. This verifies correctly as it has not been changed. Finally, the recipient checks to see if the Id of the SOAP Body was actually referenced in the signature (which it was, even though the SOAP Body itself was not signed).

    Apache WSS4J has a built-in guard against this kind of attack, whereby an ID referenced in an XML Signature cannot appear more than once in a SOAP Envelope. However, there are more sophisticated types of wrapping attacks which can defeat this defence. The crucial thing to realise is that for XML Signature you must check to see that what you are expecting to be signed was actually signed. Apache WSS4J does not perform this kind of check, instead it is left up to the third party application (Apache CXF for the purposes of this article). 

    2) Protecting against XML Signature wrapping attacks in Apache CXF

    There are two ways to configure WS-Security in Apache CXF, the recommended approach based on WS-SecurityPolicy, and the older and less sophisticated approach of specifying individual security actions to perform.

    2.1) WS-SecurityPolicy

    The WS-SecurityPolicy approach offers easy protection against signature wrapping attacks via the WS-SecurityPolicy SignedParts and SignedElements policies. The SignedElements policy takes a number of XPath expressions corresponding to the Elements that must be signed, should they be included in the request. The XPath expression must not be a relative expression for the purposes of protection against this attack.

    A more common approach is to use the WS-SecurityPolicy "SignedParts" policy. This policy allows the user to specify that the SOAP Body and any number of SOAP Headers must be signed. For example:

    <sp:Body />
    <sp:Header Name="..." Namespace="..."

    Apache CXF makes sure that the SOAP Body and any specified SOAP header is actually signed, rather that just comparing Id's as outlined in the attack scenario above, this circumventing any XML Signature wrapping attack.

    2.2) Older WS-Security approach

    The older non-policy based approach to configuring WS-Security does not perform any checking by default of what Elements were signed, and so is vulnerable to XML Signature wrapping attacks out of the box. One way to remedy this since CXF 2.2.8 is to install the CryptoCoverageChecker interceptor. This allows you to define an XPath Expression corresponding to an Element that must be signed (or encrypted). Installing this interceptor defeats an XML Signature Wrapping attack (see the wiki for more details).

    However, the CryptoCoverageChecker is somewhat complex to set up for the most common use-cases for signature verification and decryption, as it involves adding XPath expressions and the corresponding prefix/namespace pairs. In Apache CXF 2.4.9, 2.5.5 and 2.6.2, a new subclass of CryptoCoverageChecker has been introduced. The DefaultCryptoCoverageChecker provides an easy way to ensure that the SOAP Body is signed or encrypted, that the Timestamp is signed, and that the WS-Addressing ReplyTo and FaultTo headers are signed (if they are present in the message payload).

    The default configuation is that the SOAP Body, (WSU) Timestamp and WS-Addressing ReplyTo and FaultTo headers must be signed (if they exist in the message payload). This provides an out-of-the-box way of preventing XML Signature wrapping attacks. All that is required is that the DefaultCryptoCoverageChecker be added to the in-interceptor chain. I strongly recommend that you consider doing this if you are still using the older configuration for a WS-Security enabled endpoint. For example:

        <bean class="">
                    <entry key="action" value="Signature Timestamp"/>
                    <entry key="signaturePropFile" value="..."/>
                    <entry key="passwordCallbackClass"value="..."/>
        <bean class=""/>
    Categories: Colm O hEigeartaigh

    SOAP Action Spoofing Attacks on Web Services

    Thu, 09/20/2012 - 12:49
    A recent paper by Christian Mainka, Juraj Somorovsky and Jörg Schwenk at the Horst Görtz Institute for IT Security of the Ruhr University Bochum, describes an open-source tool that can be used to perform penetration testing attacks on Web Services. In particular, this tool has uncovered a vulnerability in Apache CXF to a type of SOAP Action spoofing attack, that is the content of a recently disclosed security vulnerability. This vulnerability has been fixed in versions 2.4.9, 2.5.5, and 2.6.2 of CXF.
    Each operation in a SOAP web service can be associated with a SOAP Action String, for example in the WSDL binding or via an annotation. The web service client can send the SOAP Action String as a header with the request as a way of letting the web service know what operation is required.

    In some cases, Apache CXF uses the received SOAP Action to select the correct operation to invoke, and does not check to see that the message body is correct. This can be exploitable to execute a SOAP Action spoofing attack, where an adversary can execute another operation in the web service by sending the corresponding SOAP Action. This attack only works if the different operation takes the same parameter types, and hence has somewhat limited applicability.

    This attack also only applies for web services that use unique SOAP Actions per service operation which is not the default in CXF. Also note that WS-Policy validation is done against the operation being invoked and thus the incoming message must meet those policy requirements as well, also limiting applicability.
    Categories: Colm O hEigeartaigh

    Apache WSS4J 1.6.7 released

    Fri, 08/03/2012 - 13:04
    Apache WSS4J 1.6.7 has been released. The release notes are available here. The main features of the release are:
    • A critical fix for a concurrency bug in the MemoryReplayCache
    • Subject DN Certificate Constraint support (as blogged previously).
    • A number of relatively minor fixes identified by interop testing with WCF.
    • A fix that prevented the 1.6.6 release from being deployed in an OSGi container.
    Categories: Colm O hEigeartaigh

    Subject DN Certificate Constraint support in Apache WSS4J and CXF

    Thu, 08/02/2012 - 17:18
    Apache WSS4J 1.6.7 features support for specifying constraints on the subject DN of the certificate used for signature validation. This functionality will also be available in the forthcoming Apache CXF 2.6.2, 2.5.5 and 2.4.9 releases.

    After a successful signature validation using a certificate referenced in the KeyInfo structure of an XML Signature, the next step is to establish trust in the certificate. The term "direct trust" applies to when the certificate is contained directly in the signature keystore. In this case, certificate constraints are not required as we "directly trust" the certificate. The term "chain trust" refers to when the issuing certificate of the certificate used for signature validation is contained in the signature truststore, and the certificate path of the received certificate is verified.

    There is a potential security issue when "chain trust" is applicable. Although the certificate used for signature validation might be "trusted" in a general sense (via a trusted issuing certificate), you may not wish to accept every certificate issued by the trusted certificate. This is particularly relevant if any certificate in your signature truststore is (or can potentially be) used to issue a wide range of certificates.

    This is where the concept of constraints on the subject DN of a trusted certificate comes in. The idea is that the user can specify a list of regular expressions, one of which (note not all) must be applicable to the subject DN of a (trusted) certificate used for signature verification. These constraints are not used when the certificate is contained in the keystore (direct trust). If no cert constraints are defined, and a successful trust validation is done using "chain trust", a warning message is logged indicating that a potential security risk exists in signature validaition.

    Subject DN Cert Constraints can be configured in WSS4J by specifying a WSHandlerConstants tag, see the WSS4J configuration page for more information. To see this functionality in action take a look at the corresponding WSS4J Unit Test, which uses a cert constraint of ".*CN=Colm.*O=Apache.*". Certificate constraint support can also be enabled in CXF via the endpoint property tag "ws-security.subject.cert.constraints". See the CXF WS-SecurityPolicy for more information.
    Categories: Colm O hEigeartaigh

    SAML Web SSO profile support in Apache CXF

    Tue, 06/19/2012 - 11:57
    Apache CXF has an impressive range of security features for JAX-RS endpoints. It also has excellent documentation in this space, see for example the JAX-RS documentation for OAuth, SAML Assertions and XML Encryption/Signature.  Apache CXF 2.6.1 enhances the JAX-RS security story further by featuring support for the SAML 2.0 Web SSO profile.

    The basic standard scenario for Web SSO involves a client browser accessing a secured (JAX-RS) endpoint. The endpoint constructs a SAML AuthnRequest and includes it in redirecting the browser to a Identity Provider (IDP) for authentication (via a dialog). The IDP constructs a SAML Response, and redirects the browser to a Request Assertion Consumer Service (RACS) URI contained in the AuthnRequest.  The RACS validates the SAML Response and redirects the browser yet again to the original secured endpoint. The endpoint stores the session in a cookie (hence single sign-on) and access is granted to the resource. The following steps detail how to implement this scenario in Apache CXF using the new "cxf-rt-rs-security-sso-saml" module.

    1) JAX-RS binding filters

    The SAML 2.0 bindings specification defines HTTP redirect and HTTP POST bindings which can be used to "redirect" the client browser, e.g. from the secured endpoint to the IDP. Apache CXF 2.6.1 provides a separate JAX-RS filter to support these bindings. Therefore, the first step in securing a JAX-RS endpoint is to decide which of these two bindings to use. The SamlRedirectBindingFilter class providers support for the HTTP redirect binding, and the SamlPostBindingFilter provides support for the HTTP POST binding. Both of these filters share the following configuration properties.

    1.1) Required Configuration Properties

    Each filter implementation must be configured with the URL of the IDP, as well as the URL of the RACS. It must also be configured with a SPStateManager implementation to keep track of the Authenticated sessions. CXF ships with an EhCache based implementation:
    • SPStateManager stateProvider - An object which keeps track of authenticated sessions.
    • String idpServiceAddress - The URL of the IDP.
    • String assertionConsumerServiceAddress - The URL of the RACS. This can be a relative or absolute URL.
    1.2) Signature Configuration Properties 

    The following configuration properties are only required if you wish to sign the AuthnRequest:
    • boolean signRequest - Whether to sign the AuthnRequest or not. The default is false.
    • String signatureUsername - The keystore alias to use to sign the AuthnRequest.
    • Crypto signatureCrypto - A WSS4J Crypto object if the SAML AuthnRequest is to be signed.
    • String signaturePropertiesFile - This points to a properties file that can be used to load a Crypto instance if the SAML AuthnRequest is to be signed. 
    • CallbackHandler callbackHandler - A CallbackHandler object to retrieve the private key password used to sign the request.
    • String callbackHandlerClass - A class name that is loaded for use as the CallbackHandler object. 
    Either the "signatureCrypto" or "signaturePropertiesFile" properties must be set if "signRequest" is set to true. Similarly, either "callbackHandler" or "callbackHandlerClass" must be configured.

    1.3) Optional Configuration Properties

    Here are some optional configuration properties that can be set:
    • long stateTimeToLive - The default value (in milliseconds) that a session is valid for. The default value is 2 minutes. 
    • String issuerId - The Issuer Id value to be included in the AuthnRequest. It defaults to the Base URI.
    • AuthnRequestBuilder authnRequestBuilder - An object that constructs the AuthnRequest. It defaults to DefaultAuthnRequestBuilder.
    There are some additional optional configuration properties relating to domains and web application contexts that will be covered in more detail on the CXF wiki.

    1.4) Sample Spring configuration

    Here is a sample spring configuration extract to support the redirect binding filter which signs AuthnRequests:

    <bean id="stateManager" class=""/>

    <bean id="ssoSignedRedirectURI"  class="">
            <property name="idpServiceAddress" value="https://.../idp-sig/"/>
            <property name="assertionConsumerServiceAddress"
            <property name="stateProvider" ref="stateManager"/>
            <property name="addEndpointAddressToContext" value="true"/>
            <property name="callbackHandlerClass" value="....SSOCallbackHandler"/>
            <property name="signatureUsername" value="myservicekey"/>
            <property name="signaturePropertiesFile" value=""/>
            <property name="signRequest" value="true"/>

    <jaxrs:server address="/app1">
           <jaxrs:serviceBeans><ref bean="..."/></jaxrs:serviceBeans>
           <jaxrs:providers><ref bean="ssoRedirectURI"/></jaxrs:providers>

    2) The Request Assertion Consumer Service

    The JAX-RS filters described above take care of creating a SAML AuthnRequest, optionally signing it, and redirecting the client browser to the IDP. The next step is to define a RequestAssertionConsumerService (RACS) which will intercept the SAML Response from the IDP. The RACS processes the SAML Response, and validates it in a number of ways:
    • The SAMLProtocolResponseValidator validates the Response against the specifications and checks the signature of the Response (if it exists), as well as doing the same for any child Assertion of the Response. It validates the status code of the Response as well. 
    • The SAMLSSOResponseValidator validates the Response according to the Web SSO profile. 
    If validation is successful the RACS redirects to the service provider endpoint.

    2.1) Configuration properties shared with the filters

    The RequestAssertionConsumerService that ships with CXF shares a number of configuration properties with the filters, mainly relating to state and signature configuration:
    • SPStateManager stateProvider - An object which keeps track of authenticated sessions. This is required.
    • long stateTimeToLive - The default value (in milliseconds) that a session is valid for. The default value is 2 minutes.
    • Crypto signatureCrypto - A WSS4J Crypto object to use to validate a signed Response.
    • String signaturePropertiesFile - This points to a properties file that can be used to load a Crypto instance for signature validation.
    • CallbackHandler callbackHandler - A CallbackHandler object to retrieve the private key password used to decrypt an encrypted request.
    • String callbackHandlerClass - A class name that is loaded for use as the CallbackHandler object.  
    Only the "stateProvider" property is required. Either the "signatureCrypto" or "signaturePropertiesFile" properties must be set if you wish to support verifying signed Responses, or signed Assertions contained in a Response. Similarly, either "callbackHandler" or "callbackHandlerClass" must be configured if you wish to support decrypting encrypted Assertions. 

    2.2) Additional Optional Configuration properties

    The RACS supports the following additional (optional) configuration properties:
    • boolean supportDeflateEncoding - Whether Deflate encoding is used to inflate a token received via the Redirect binding. The default is true.
    • boolean supportBase64Encoding - Whether the token is Base64 decoded or not. The default is true.
    • boolean enforceAssertionsSigned - Whether the Assertions contained in a Response must be signed or not. The default is true.
    • boolean enforceKnownIssuer - Whether the Issuer of the Response (and child Assertions) is "known" to the RACS. This value is compared against the IDP URL configured on the filter. The default value is true.
    • TokenReplayCache<String> replayCache - A TokenReplayCache implementation to store Assertion ID's for the POST binding to guard against replay attacks. The default uses an implementation based on EhCache.
    2.4) Sample Spring Configuration

    Here is a sample spring configuration extract to set up a RACS, that could be used with the filter configuration in section 1.4:

     <bean id="consumerService" class="">
            <property name="stateProvider" ref="stateManager"/>
            <property name="signaturePropertiesFile" value=""/>
            <property name="enforceKnownIssuer" value="false"/>
            <property name="callbackHandlerClass" value="...SSOCallbackHandler"/>

    3) The Identity Provider (IDP)

    The remaining piece of the puzzle is the Identity Provider (IDP) which receives the SAML AuthnRequest from the service provider, processes it accordingly, and then interacts with the client browser to authenticate the client. It then creates a SAML Response and redirects the client browser to the RACS defined in the AuthnRequest. Apache CXF does not (yet) ship with an IDP, although this may change in the near future. However, there are a number of open-source IDPs that can be used with a CXF JAX-RS endpoint that supports SAML Web SSO. These include Shibboleth, PicketLink, OpenAM, JOSSO, etc. I have tested against all of these products. Report any interop issues to the CXF JIRA.

    4) Ongoing Development

    SAML Web SSO profile support is still being actively developed. A number of bugs have been fixed that do not yet appear in a released version of CXF. For example, support for decrypting encrypted Assertions in a SAML Response, and some bugs relating to signed Assertions (CXF-4352 and CXF-4365).
    Categories: Colm O hEigeartaigh

    Simplified Apache CXF STS configuration

    Thu, 06/14/2012 - 15:29
    The Apache CXF STS configuration options have been covered in detail in previous posts on this blog. Following some suggestions by Glen Mazza, a new simplified way of configuring the STS will be available in Apache CXF 2.6.2. This new configuration is essentially a simpler and more intuitive way of catering for the most common STS scenarios. The older configuration style is still fully supported.

    An example of how to configure the CXF STS using the old configuration is available here. It involves a mixture of the STS Provider API that lives in the WS-Security module in CXF, and the concrete STS functionality that is available in the STS services module in CXF. The SecurityTokenServiceProvider in the CXF API is instantiated with implementations of the various Operations (Issue/Validate/etc.) that are available in the CXF STS. However, the flexibility of this approach leads to a slightly verbose configuration style, which is perhaps overly complicated for the most common use-cases.

    An example of the simpler configuration approach is available here. Rather than use the SecurityTokenServiceProvider in the CXF API, it uses a sub-class in the CXF STS (DefaultSecurityTokenServiceProvider). This implementation supports the issue and validate bindings by default. It also supports the ability to issue and validate SAML Tokens, and to validate UsernameTokens and X.509 Tokens. Therefore, for any of these use-cases there is no need to use the old-style configuration, which involves explicitly instantiating each TokenProvider or TokenValidator instance and setting them on an IssueOperation/ValidateOperation instance.  However, if you want to use the renew or cancel bindings, or do anything with SecurityContextTokens, it's necessary to use the old configuration.

    The DefaultSecurityTokenServiceProvider can be configured with the following (optional) properties:
    • boolean encryptIssuedToken - Whether to encrypt the issued token or not. The default is false.
    • List<ServiceMBean> services - A list of service endpoints to support. See here for more information.
    • boolean returnReferences - Whether to return references to an issued token or not. The default is true.
    • TokenStore tokenStore - The TokenStore caching implementation to use. See here for more information.
    • ClaimsManager claimsManager - The ClaimsManager to use if you want to be able to handle claims. See here for more information.
    Categories: Colm O hEigeartaigh

    New security vulnerabilities in Apache CXF

    Thu, 06/07/2012 - 11:50
    Two new security vulnerabilities have been announced in Apache CXF. Those of you using WS-SecurityPolicy should read the announcements carefully to make sure that you are not affected. If these vulnerabilities apply to your deployment then you should upgrade to a more recent version of CXF that contains fixes for these vulnerabilities. The issues in question are:
    • CVE-2012-2378 - Apache CXF does not pick up some child policies of
      WS-SecurityPolicy 1.1 SupportingToken policy assertions on the client
    • CVE-2012-2379 - Apache CXF does not verify that elements were
      signed or encrypted by a particular Supporting Token.

    Categories: Colm O hEigeartaigh