Colm O hEigeartaigh

New SAML validation changes in Apache WSS4J and CXF

Colm O hEigeartaigh - Tue, 02/03/2015 - 18:27
Two new Apache WSS4J releases are currently under vote (1.6.18 and 2.0.3). These releases contain a number of changes in relation to validating SAML tokens. Apache CXF 2.7.15 and 3.0.4 will pick up these changes in WSS4J and enforce some additional constraints. This post will briefly cover what these new changes are.

1) Security constraints are now enforced on SAML Authn (Authentication) Statements

From the 1.6.18 and 2.0.3 WSS4J releases, security constraints are now enforced on SAML 2.0 AuthnStatements and SAML 1.1 AuthenticationStatements by default. What this means is that we check that:
  • The AuthnInstant/AuthenticationInstant is not "in the future", subject to a configured future TTL value (60 seconds by default).
  • The SessionNotOnOrAfter value for SAML 2.0 tokens is not stale / expired.
  • The Subject Locality (IP) address is either a valid IPv4 or IPv6 address.
2) Enforce constraints on SAML Assertion "IssueInstant" values

We now enforce that a SAML Assertion "IssueInstant" value is not "in the future", subject to the configured future TTL value (60 seconds by default). In addition, if there is no "NotOnOrAfter" Condition in the Assertion, we now enforce a TTL constraint on the IssueInstant of the Assertion. The default value for this is 30 minutes.

3) Add AudienceRestriction validation by default

The new WSS4J releases allow the ability to pass a list of Strings through to the SAML validation code, against which any AudienceRestriction address of the assertion are compared. If the list that is passed through is not empty, then at least one of the AudienceRestriction addresses in the assertion must be contained in the list. Apache CXF 3.0.4 and 2.7.15 will pass through the endpoint address and the service QName by default for validation (for JAX-WS endpoints). This is controlled by a new JAX-WS security property:
  • ws-security.validate.audience-restriction: If this is set to "true", then IF the SAML Token contains Audience Restriction URIs, one of them must match either the request URL or the Service QName. The default is "true" for CXF 3.0.x, and "false" for 2.7.x.
Categories: Colm O hEigeartaigh

LDAP support in Apache Camel

Colm O hEigeartaigh - Wed, 01/28/2015 - 17:29
Apache Camel allows you to add LDAP queries to your Camel routes via the camel-ldap and camel-spring-ldap components. The camel-ldap component allows you to perform an LDAP query using a filter as the message payload. The spring-ldap component is a wrapper for Spring LDAP, and is a bit more advanced than the camel-ldap component, in that it also supports the "bind" and "unbind" operations, in addition to "search".

I've created two test-cases that show how to use each of these components. Both test-cases use the Camel file component to read in files that contain LDAP queries. These queries are then dispatched to an Apache DS server that is configured via annotations in the test code, using an LDIF file containing some test data. The results are then processed and written out in the target directory. The test-cases are available here
Categories: Colm O hEigeartaigh

Apache Santuario - XML Security for Java 2.0.3 and 1.5.8 released

Colm O hEigeartaigh - Mon, 01/19/2015 - 16:53
Versions 2.0.3 and 1.5.8 of Apache Santuario - XML Security for Java have been released. Version 2.0.3 contains a critical security advisory (CVE-2014-8152) in relation to the new streaming XML Signature support introduced in version 2.0.0:
For certain XML documents, it is possible to modify the document and the streaming XML Signature verification code will not report an error when trying to validate the signature.

Please note that the "in-memory" (DOM) API for XML Signature is not affected by this issue, nor is the JSR-105 API. Also, web service stacks that use the streaming functionality of Apache Santuario (such as Apache CXF/WSS4J) are also not affected by this vulnerability.Apart from this issue, version 2.0.3 contains a significant performance improvement, and both releases contain minor bug fixes and dependency upgrades.
Categories: Colm O hEigeartaigh

XML Advanced Electronic Signature (XAdES) support in Apache Camel

Colm O hEigeartaigh - Wed, 01/14/2015 - 12:43
I have previously covered some XML Signature and Encryption testcases in Apache Camel. Camel 2.15 will feature some new limited support for XML Advanced Electronic Signatures (XAdES) in the XML Security component. This post will briefly cover what XML Advanced Electronic Signatures are, and show how they can be produced in Camel. No support exists yet for validating XAdES Signatures in Camel. Note that as Camel 2.15 is not yet released, some of the details are subject to change.

XML Signature has a number of shortcomings in terms of conveying meta-data describing the signing process to the recipient. It does not include the signing certificate/key in the signature itself. It does not tell the recipient when or where the signature was created, which role the signer had at the time of signing, what format the signed data is in, what the signature policy was, etc. XAdES attempts to solve these problems by introducing standard properties that are inserted into the "Object" part of an XML Signature. Some of these properties are then included in the message signature.

Camel 2.15 will support XAdES in the XML Security component by a new "properties" configuration option, which must reference a XAdESSignatureProperties implementation. I added a new test to the camel-xmlsecurity project in github that illustrates how to do this. The spring configuration for the test is here. The xmlsecurity route links to a DefaultXAdESSignatureProperties implementation, which is configured with the signing key (and alias), an "Implied" Signature policy, and a role of "employee". The resulting ds:Object in the XML Signature looks like:

  <etsi:QualifyingProperties xmlns:etsi="..." Target="#...">
    <etsi:SignedProperties Id="_1c03790b-8e46-4837-85bc-d6562e4c713c"> 
              <ds:DigestMethod Algorithm="...#sha256"/>
Categories: Colm O hEigeartaigh

Signing and encrypting Apache Camel routes

Colm O hEigeartaigh - Mon, 01/12/2015 - 16:02
A recent blog post looked at using the XML Security component and dataformat in Apache Camel to sign and encrypt XML documents. However, what if you wish to secure non-XML data? An alternative is to use the Apache Camel Crypto component and dataformat. The Crypto component provides the ability to sign (and verify) messages (using the JCE). Similarly, the Crypto dataformat allows you to encrypt (and decrypt) messages (again using the JCE). Another alternative is to use the PGPDataFormat, which allows you to use PGP to sign/encrypt Camel messages.

I have created a github project called "camel-crypto" with some samples about how to use these features. It contains the following tests:
The tests follow a similar pattern, where they take some (XML) data, sign/encrypt it, and copy it to a particular directory. Another route then takes the secured data, and verifies/decrypts it, and copies it to another directory. The tests also show how to use the Camel Jasypt component to avoid hard-coding plaintext passwords in the spring configuration files. The tests rely on a SNAPSHOT version of Camel (2.15-SNAPSHOT) at the time of writing this post, due to some fixes that were required (particularly in terms of adding new (Spring) configuration options to the PGPDataFormat).
Categories: Colm O hEigeartaigh

New SSL/TLS vulnerabilities in Apache CXF

Colm O hEigeartaigh - Mon, 12/22/2014 - 13:01
Apache CXF 3.0.3 and 2.7.14 have been released. Both of these releases contain fixes for two new SSL/TLS security advisories:
  • Note on CVE-2014-3566: This is not an advisory per se, but rather a note on an advisory. CVE-2014-3566 (aka "POODLE") is a well publicised attack which forces a TLS connection to downgrade to use SSL 3.0, which in turn is vulnerable to a padding oracle attack. Apache CXF 3.0.3 and 2.7.14 disable SSL 3.0 support by default for both clients, as well as servers configured using CXF's special support for Jetty. In addition, it is now possible to explicitly exclude protocols, see here for more information.
  • CVE-2014-3577: Apache CXF is vulnerable to a possible SSL hostname verification bypass, due to a flaw in comparing the server hostname to the domain name in the Subject's DN field. A Man In The Middle attack can exploit this vulnerability by using a specially crafted Subject DN to spoof a valid certificate.
If you are using TLS with Apache CXF then please upgrade to the latest releases.
Categories: Colm O hEigeartaigh

XML Security using Apache Camel

Colm O hEigeartaigh - Tue, 12/02/2014 - 15:48
I have previously covered how to use Apache Santuario to sign and encrypt XML, using both the DOM and StAX based APIs available in the 2.0.x releases. An alternative to using Apache Santuario directly to sign/encrypt XML, is to use the XML Security component or data format of Apache Camel. There are two obvious reasons to use Camel that immediately spring to mind. Firstly it allows you to configure XML Signature/Encryption without writing any code (e.g. by configuring the components in Spring). Secondly it allows you to take advantage of the power and flexibility of Apache Camel to integrate with a wide variety of components.

I have created a github project with two (almost identical) tests to show how to use XML Signature and Encryption in Apache Camel:
Both tests start routes which read in XML documents stored in src/test/resources/data using the Camel File component. The part of the documents which contain credit card information is then signed/encrypted, and the resulting file placed in the target/(encrypted/signed)-data folder. A second route reads files in from this folder, decrypts/verifies the file and then places it in the target/(decrypted/verified)-data folder.

The encryption configuration file is available here, and the signature configuration file is here. One difference you may notice is that encryption is configured using a "marshal/unmarshal" tag and then "secureXML", whereas for signature you can use a standard Camel "To" statement, e.g. "
<to uri="xmlsecurity:sign://enveloped?keyAccessor...". This is due to the fact that XML Encryption is implemented in Camel as a data format, whereas XML Signature is implemented as a component.

Both tests also use the Camel Jasypt component to avoid hard-coding plaintext passwords in the spring configuration files. The keystore and private key passwords and stored encrypted in a special passwords file. The master secret used to decrypt the passwords is retrieved via a system property (set in the pom.xml as part of the tests).

The testcase relies on a SNAPSHOT version of Apache Camel for now (2.15-SNAPSHOT) due to a number of fixes I added. Firstly, the DefaultKeySelector used to retrieve keys for signature did not previously support taking a Camel
keyStoreParameters Object. Secondly, the DefaultKeySelector did not support working with the Camel Jasypt component to encrypt the keystore password.  Thirdly, it wasn't possible to load a Public Key from a PrivateKeyEntry in a Keystore for XML Signature. Fourthly, the XML Encryption data format did not support embedding the KeyValue of the Public Key used to encrypt the session key in the EncryptedKey structure.
Categories: Colm O hEigeartaigh

Apache Syncope 1.2 tutorial - part IV

Colm O hEigeartaigh - Thu, 11/13/2014 - 17:19
This is the fourth and final post in a series of articles on Apache Syncope 1.2. The previous tutorial looked at some new features relating to the Schema in Apache Syncope 1.2. This post will look at the REST API of Syncope and how it can be queried. We will also look at the new JAAS LoginModule for Apache Syncope that has been developed in Apache Karaf.

1) REST API of Apache Syncope

Apache Syncope features a rich REST API powered by Apache CXF. It is available via the URI "/syncope/rest/". Note that Apache Syncope 1.1 featured two REST APIs, one powered by Spring and another by Apache CXF, which was a refactoring of the former based on RESTful best practices. The Spring based API has been dropped in Apache Syncope 1.2, and only the CXF based API is now available via the "/syncope/rest" URI. Here are some example REST GET URIs for the "User" service in Syncope 1.2, that you can try out in a browser:
  • syncope/rest/users.json - get a list of all users in JSON format
  • syncope/rest/users - get a list of all users in an XML format
  • syncope/rest/users/self - get the authenticated user
Apache Syncope 1.2 uses the WADL generation capabilities of Apache CXF to expose the REST API as a WADL document. This can be accessed by adding "?_wadl" to the URI, for example "syncope/rest/?_wadl":

This document can be converted to HTML, see here for an example for Apache Syncope. Another new feature of the REST API in Apache Syncope 1.2 is support for FIQL. This allows you to easily search for users or roles matching a certain expression. For example:
  • syncope/rest/users/search?_s=lastLoginDate=ge=2014-11-13 - Search for the users who have logged in since 20014/11/13.
  • syncope/rest/users/search?_s=surname==smith - Search for the users with surname 'smith'.

2) JAAS LoginModule for Syncope

In a previous blog post written about the REST API of Apache Syncope, I gave detailed of a github project with some CXF based testcases. The tests showed how a CXF service could use Apache Syncope to authenticate a WS-Security UsernameToken presented by a client (as well as HTTP/BA). In addition, some other tests asked Syncope for the roles associated with the user, and enforced access to the service depending on the result. This github project has now moved to a new location here, and the tests have been updated to use the correct URLs for Apache Syncope 1.2.

In addition, a new test is added that shows how to use the new JAAS LoginModule for Syncope for authentication and authorization. The SyncopeLoginModule was developed for use in Apache Karaf, but can be used in others containers as well. In the testcase, the CXF JAASAuthenticationFeature is set on the service bus, which selects the "karaf" JAAS realm by default. The JAAS configuration file for the test is simply:

karaf {
    org.apache.karaf.jaas.modules.syncope.SyncopeLoginModule required

See Jean-Baptiste Onofré's blog for a further description of how to set up and test the SyncopeLoginModule.
Categories: Colm O hEigeartaigh

Apache Syncope 1.2 tutorial - part III

Colm O hEigeartaigh - Mon, 11/10/2014 - 17:59
This is the third in a series of articles on the new features of Apache Syncope 1.2. The first article covered installing Syncope using the new UI installer. The second article demonstrated some new features of Apache Syncope 1.2 when working with backend resources, namely the ability to synchronize and propagate encrypted passwords. This post focuses on some new features associated with schemas in Syncope 1.2.

Apache Syncope uses the concept of a schema to define attributes for User, Roles and Memberships (the relationship of a User with a Role). You can define the attribute name, the type, whether it is multi-valued, whether it is unique or read-only, whether it is stored internally or remotely, etc. There are three new interesting features in Syncope 1.2 in the area of Schemas:
  • Configuration Schema: The Configuration parameters are now covered by the Schema. You can add new attributes for the Configuration section in the Schema section.
  • Encrypted Schema attributes: A new "Encrypted" attribute type is available. This will ensure that Syncope always keeps the attribute value encrypted with the specified key.
  • Binary Schema attributes: A new "Binary" attribute type is available.
We will now focus on this latter feature. We will show how to use binary attributes with two examples. Start Apache Syncope + set up the LDAP Connector + Resource as covered in the first two tutorials.

1) Import X.509 Certificates into Syncope

The first use-case for binary schema attributes is to allow the synchronization of X.509 Certificates into Syncope from a backend resource. Go to the "Schema" tab, and create a new "User" attribute called "certificate" of type "Binary", and with mime type "application/x-x509-user-cert":

Next, go into the LDAP Resource configuration and add a new user mapping from the "certificate" attribute of the "UserSchema" to the LDAP "userCertificate" attribute. Now make sure that you have a user in your LDAP backend with a "userCertificate" attribute defined as follows:

Finally, run the synchronization task in Syncope. The user now has the certificate added as an attribute, which can be downloaded or else retrieved via the REST API:

2) Import images into Syncope

Another common use-case for binary attributes is to import images into Syncope. Create a new binary User attribute in the Schema called "image" of type "image/jpeg", and a new User mapping for the LDAP Connector mapping it to the LDAP "jpegPhoto" attribute. Assuming that a user in the LDAP backend has such an attribute defined, the newly synchronized User will look like this:

Categories: Colm O hEigeartaigh

Apache Syncope 1.2 tutorial - part II

Colm O hEigeartaigh - Fri, 11/07/2014 - 17:32
The previous tutorial on the new features of Apache Syncope 1.2 showed how to use the new UI installer to deploy Apache Syncope to Apache Tomcat, using MySQL for persistent storage. Last year we covered how to import users (and roles) from backend resources such as a database or a directory. An important new feature of Apache Syncope 1.2 is the ability to import non-cleartext passwords into Syncope when synchronizing from backend resources (and also the ability to propagate non-cleartext passwords to resources). The default behaviour is to hash the password according to the global configuration parameter 'password.cipher.algorithm' (defaults to SHA-1). This is problematic if the password is already hashed, as user authentication via the Syncope REST API will then fail.

1) Create policies in Apache Syncope

The first step is to start Apache Syncope and to create some policies for account and password creation, as well as synchronization. Start Syncope and go to the Configuration tab. Select "Policies" and create new "global" policy types for both "Account", "Password" and "Synchronization", with some sensible default values.

2) Synchronizing non-cleartext passwords from Apache Derby.

This is an update from the previous blog entry on importing users from Apache Derby using Syncope 1.1. Follow step 1 "Creating a Schema attribute" and step 2 "Apache Derby" in the previous blog. However, in section 2.b, rather than adding users with plaintext passwords, use the following user value instead when creating a table:

INSERT INTO USERS VALUES('dave', '8eec7bc461808e0b8a28783d0bec1a3a22eb0821', 'true', 'yellow');

Instead of using a plaintext password value, the second field is the SHA-1 encoded value of "security". In section 3.a "Define a Connector", it is necessary to change the "Password cipher algorithm" value from "CLEARTEXT" to "SHA1". In step 3.b "Define a Resource", it is necessary to specify an external attribute for the Username mapping of "NAME". Finally, in step 3.c "Create a synchronization task", use the "DBSyncPasswordActions" action class. This class treats the password retrieved from the table as encoded according to the "Password cipher algorithm" parameter of the Connector ("SHA1" in this case), and to store it directly in Syncope without subsequently hashing it again, which is what would happen for the plaintext case. Note that the presumption is that the (hashed) password is HEX encoded in the table.

After executing the synchronization task, then start a browser and navigate to "http://localhost:8080/syncope/rest/users/self", logging on as "dave" and "security".

3) Synchronizing non-cleartext passwords from Apache DS.

This is an update from the previous blog entry on importing users and roles from an LDAP backend such as Apache DS into Apache Syncope 1.1. Follow the first step in the previous tutorial to set up Apache DS and import users and groups. Add some users, e.g. "colm", this time with a SHA-256 encoded password. Importing users with encoded passwords from LDAP is a bit more sophisticated than the DB case above, because individual users can have different digest algorithms with the LDAP synchronization case, whereas all users must have the same digest algorithm for the DB synchronization case.

Start up Syncope, and follow the steps given in the previous tutorial to create a new connector and resource. The only difference with Syncope 1.2 is that you need to specify the external attribute for both the Username and Rolename mapping ("cn" in both cases for this example). Finally, create the Synchronization task as per the previous tutorial. However this time add both the LDAPPasswordSyncActions and LDAPMembershipSyncActions classes as "Actions classes". Finally execute the task, and check to see if the users + roles were imported successfully into Syncope. You can then log on via
"http://localhost:8080/syncope/rest/users/self" using any of the users imported from Apache DS, regardless of the internal cipher algorithm that was used.
Categories: Colm O hEigeartaigh

Apache Syncope 1.2 tutorial - part I

Colm O hEigeartaigh - Thu, 11/06/2014 - 13:26
Apache Syncope is a powerful and flexible open source tool to manage and orchestrate user identities for the enterprise. Last year, I wrote a series of four tutorials on Apache Syncope. The first covered how to create an Apache Syncope project, how to set up a MySQL database for internal storage, and how to deploy Apache Syncope to Apache Tomcat. The second covered how to import user identities and attributes from a database (Apache Derby) into Syncope. The third covered how to import users and roles from an LDAP backend (Apache DS) into Syncope. Finally, the fourth tutorial covered the REST API of Apache Syncope, as well as a set of Apache CXF-based testcases to demonstrate how to use the REST API of Apache Syncope for authentication and authorization.

This will be the first post in a new set of tutorials for Apache Syncope, with a focus on updating the previous set of tutorials (based on Syncope 1.1) with some updated features and new functionality that is available in the recently released 1.2.0 release. In this post we will cover how to use the new UI installer for creating a Apache Syncope project and deploying it to a container. This tutorial can be viewed as a more user-friendly alternative to the first tutorial of the previous series. Please also see the Syncope documentation on using the installer.

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. The next step is to enable a way to deploy applications to Tomcat using the Manager app. Edit 'conf/tomcat-users.xml' and add the following:

<role rolename="manager-script"/>
<user username="manager" password="s3cret" roles="manager-script"/>

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) Run the Installer

Download and run the installer via 'java -jar syncope-installer-1.2.0-uber.jar'. You need to enter some straightforward values such as the installation path of the project, the Apache Maven home directory, the groupId/artifactId of the project, the directories where logs/bundles/configuration are stored.

Next, select "MySQL" as the database technology from the list, and give "syncope_user" and "syncope_pass" as the username + password, or whatever you have configured earlier when setting up MySQL. Select "Tomcat" as the application server (make sure the 'syncopeDataSource' is checked), and enter values for the address, port, manager username and password:

The installer will then create a Apache Syncope project + deploy it to Tomcat:

When the installer has finished, startup a browser and go to "localhost:8080/syncope-console", logging in as "admin/password". You should see the following:

Categories: Colm O hEigeartaigh

Security semantics of SAML SubjectConfirmation methods in Apache WSS4J/CXF

Colm O hEigeartaigh - Mon, 11/03/2014 - 17:27
A recent blog post covered two new security advisories issued for Apache CXF in relation to SAML tokens. In particular, one advisory dealt with the enforcement of the security semantics of SAML SubjectConfirmation methods when used with the TransportBinding:
There are different security requirements associated with SAML
SubjectConfirmation methods. These security requirements are not properly enforced in Apache CXF when used with the TransportBinding, leaving endpoints that rely on SAML for authentication vulnerable to types of spoofing attacks.In this post I will recap the security requirements that are associated with SAML SubjectConfirmation methods in the latest CXF releases:
  • Holder-of-Key: If the subject confirmation method is "holder-of-key", there must be some proof-of-possession of the key associated with the subject of the assertion. CXF will enforce that either the key was used to sign some portion of the SOAP request, or alternatively the subject credential of the SAML Assertion must match a client certificate credential when TLS with client authentiction is used.
  • Sender-Vouches: If the subject confirmation method is "sender-vouches", then CXF will enforce that the SAML Assertion and SOAP Body are signed by the same signature. Alternatively, it will check that TLS with client authentication is used.
  • Bearer: The SAML Assertion must be signed (with an internal XML Signature) by default. This can be configured in the latest WSS4J releases.
In addition, the SamlAssertionValidator in WSS4J now enforces that at least one of the standard SubjectConfirmation methods (as listed above) is present. It is also possible to specify a given SubjectConfirmation method that is required.
Categories: Colm O hEigeartaigh

Using Apache JMeter to load test Apache CXF endpoints

Colm O hEigeartaigh - Fri, 10/31/2014 - 18:32
Apache JMeter is a graphical tool that can be used to load-test your web applications. I created a new project in my github repo that creates a web application with a number of CXF endpoints, as well as a JMeter configuration file that can be used to load test the endpoints. The benefit of doing this kind of testing is to figure out how responsive various (security) protocols might be under load. In addition, the project uncovered a couple of threading issues surrounding policy handling, which were fixed by Dan Kulp in CXF 3.0.1.

The endpoints that are exposed in the application are:
  • /doubleit/services/doubleitnosecurity - No security at all. This can be used to test throughput over plaintext and TLS.
  • /doubleit/services/doubleittransport - This uses a Transport binding with a UsernameToken supporting token. The UsernameToken is just validated by a simple CallbackHandler on the service side. 
  • /doubleit/services/doubleitsymmetric - This uses a Symmetric binding with a UsernameToken supporting token. The UsernameToken is just validated by a simple CallbackHandler on the service side. 
  • /doubleit/services/doubleitsymmetricstreaming - This is the same as per the symmetric case above, except that it uses the new streaming WS-Security implementation available in Apache CXF 3.0.0. 
  • /doubleit/services/doubleitasymmetric - This uses a Asymmetric binding. Authentication is established by a certificate chain. 
  • /doubleit/services/doubleitasymmetricstreaming - Same as for the asymmetric case above, except that it uses the new streaming WS-Security implementation available in Apache CXF 3.0.0. 
Simply build the project with "mvn clean install" and drop the resulting .war file into your container (e.g. Apache Tomcat). Then start up JMeter + import the configuration file and run the tests.

    Categories: Colm O hEigeartaigh

    Two new security advisories for Apache CXF

    Colm O hEigeartaigh - Fri, 10/24/2014 - 20:10
    Two new security advisories have been released for Apache CXF, please see the CXF security advisories page for the details:
    • CVE-2014-3623: Apache CXF does not properly enforce the security semantics of SAML SubjectConfirmation methods when used with the TransportBinding
    • CVE-2014-3584: Apache CXF JAX-RS SAML handling is vulnerable to a Denial of Service (DoS) attack
    If you are using SAML SSO or else SAML tokens with the WS-SecurityPolicy Transport binding you should upgrade to either CXF 2.7.13 or 3.0.2.
    Categories: Colm O hEigeartaigh

    Apache CXF Authentication and Authorization test-cases IV

    Colm O hEigeartaigh - Thu, 10/23/2014 - 16:36
    This is the fourth in a series of posts on authentication and authorization test-cases for web services using Apache CXF. The first focused on different ways to authenticate and authorize UsernameTokens for JAX-WS services. The second looked at more advanced examples such as using Kerberos, WS-Trust, XACML, etc. The third looked at different ways of achieving SSO in CXF for both JAX-WS and JAX-RS services. This post gives some examples of authenticating and authorizing JAX-RS services in Apache CXF. I also included the SSO examples relevant to JAX-RS from the previous post. The projects are:
    • cxf-jaxrs-xmlsecurity: This project shows how to use XML Signature (and Encryption) to secure JAX-RS services. In particular, see the AuthenticationTest.
    • cxf-jaxrs-sts: This project demonstrates how to use HTTP/BA for authentication for JAX-RS, where the credentials are dispatched as a UsernameToken are dispatched to an STS instance for authentication. In addition, the project shows how to authorize the request by asking the STS for a SAML Token containing the roles of the user.
    • cxf-kerberos: This project (covered previously for JAX-WS) has been updated with a test that shows how to use Kerberos with JAX-RS.
    • 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 CXF Fediz 1.1.2 released

    Colm O hEigeartaigh - Wed, 10/22/2014 - 12:32
    Apache CXF Fediz 1.1.2 has been released. Apache CXF Fediz is a Single Sign-On (SSO) solution based on the WS-Federation Passive Requestor Profile. It consists of an Identity Provider (IdP) which leverages the Apache CXF STS to issue tokens, as well as a number of container-specific plugins (Jetty, Tomcat, Spring, etc.) to enable SSO for web applications. The issues fixed in the new release include an upgrade to CXF 2.7.13, support for claims mapping in the STS, kerberos authentication support in the IdP, amongst other fixes.
    Categories: Colm O hEigeartaigh

    Kerberos Credential Delegation support in Apache CXF

    Colm O hEigeartaigh - Tue, 10/21/2014 - 15:25
    Apache CXF provides full support for integrating Kerberos with JAX-WS and JAX-RS services. A previous tutorial (here and here) described how to set up Kerberos with WS-Security in CXF, where the client obtains a Kerberos service ticket and encodes it in the security header of the request, and where it is validated in turn by the service. In this post we will discuss support for kerberos credential delegation for JAX-WS clients and services in Apache CXF. For more information on using kerberos with JAX-RS please consult the CXF documentation.

    1) Kerberos Client Configuration

    CXF provides a number of JAX-WS properties that can be used to configure Kerberos on the client side (documented here under "Kerberos Configuration Tags"). Essentially there are two different ways of doing it. The client must explicitly allow kerberos credential delegation by setting a property.

    1.1) Create and configure a KerberosClient Object directly

    The KerberosClient in the CXF WS-Security runtime module is used to retrieve a kerberos ticket. It can be configured by setting various properties and then referenced via the JAX-WS property:
    • ws-security.kerberos.client - A reference to the KerberosClient class used to obtain a service ticket.
    The "requestCredentialDelegation" property of the KerberosClient must be set to "true" to allow credential delegation. Here is an example in Spring:

    <bean class="" id="kerberosClient">
            <constructor-arg ref="cxf"/>
            <property name="contextName" value="bob"/>
            <property name="serviceName" value=""/>
            <property name="requestCredentialDelegation" value="true"/>

    <jaxws:client name="{service}port" createdFromAPI="true">
                <entry key="ws-security.kerberos.client" value-ref="kerberosClient"/>

    1.2) Use JAX-WS properties to configure Kerberos

    Rather than use the KerberosClient above, it is possible to configure Kerberos via JAX-WS properties:
    • ws-security.kerberos.jaas.context - The JAAS Context name to use for Kerberos.
    • ws-security.kerberos.spn - The Kerberos Service Provider Name (spn) to use.
    • - Whether the Kerberos username is in servicename form or not.
    • ws-security.kerberos.use.credential.delegation - Whether to use credential delegation or not in the KerberosClient.
    • ws-security.kerberos.request.credential.delegation - Whether to request credential delegation or not in the KerberosClient.
    The latter property must be set to "true" on the client side to allow kerberos credential delegation.

    2) Kerberos Service Configuration

    A JAX-WS service validates a kerberos ticket received in the security header of a request via a KerberosTokenValidator. Here is an example:

    <bean id="kerberosValidator"
            <property name="contextName" value="bob"/>
            <property name="serviceName" value=""/>
    <jaxws:endpoint ...>
                <entry key="ws-security.bst.validator" value-ref="kerberosValidator"/>
    3) Using Kerberos Credential Delegation

    After a service has validated a kerberos token sent by the client, it can obtain another kerberos token "on behalf of" the client, assuming the client enabled credential delegation in the first place. To use the client credential for delegation the "useDelegatedCredential" property of the KerberosClient must be set to "true" (see here), or else the JAX-WS property "ws-security.kerberos.use.credential.delegation" must be set to "true" if not configuring Kerberos via the KerberosClient Object.

    To see how a concrete use-case for this functionality, take a look at the KerberosDelegationTokenTest in the CXF STS advanced systests. Here we have a backend service which requires a SAML Token issued by an STS. However, the clients only know how to obtain a Kerberos token. So we have an intermediary service which requires a Kerberos token. The clients enable credential delegation + send a ticket to the Intermediary. The Intermediary validates the ticket, then uses it to obtain a Kerberos token "OnBehalfOf" the client, which in turn is used to authenticate to the STS + retrieve a SAML Token, which is then forwarded on to the backend service.
    Categories: Colm O hEigeartaigh

    Using JAAS with Apache CXF

    Colm O hEigeartaigh - Tue, 10/14/2014 - 15:14
    Apache CXF supports a wide range of tokens for authentication (SAML, UsernameTokens, Kerberos, etc.), and also offers different ways of authenticating these tokens. A standard way of authenticating a received token is to use a JAAS LoginModule. This article will cover some of the different ways you can configure JAAS in CXF, and some of the JAAS LoginModules that are available.

    1) Configuring JAAS in Apache CXF

    There are a number of different ways to configure your CXF web service to authenticate tokens via JAAS. For all approaches, you must define the System property "" to point towards your JAAS configuration file.

    1.1) JAASLoginInterceptor

    CXF provides a interceptor called the JAASLoginInterceptor that can be added either to the "inInterceptor" chain of an endpoint (JAX-WS or JAX-RS) or a CXF bus (so that it applies to all endpoints). The JAASLoginInterceptor typically authenticates a Username/Password credential (such as a WS-Security UsernameToken or HTTP/BA) via JAAS. Note that for WS-Security, you must tell WSS4J not to authenticate the UsernameToken itself, but just to process it and store it for later authentication via the JAASLoginInterceptor. This is done by setting the JAX-WS property "ws-security.validate.token" to "false".

    At a minimum it is necessary to set the "contextName" attribute of the JAASLoginInterceptor, which references the JAAS Context Name to use. It is also possible to define how to retrieve roles as part of the authentication process, by default CXF assumes that Objects are interpreted as "role" Principals. See the CXF wiki for more information on how to configure the JAASLoginInterceptor. After successful authentication, a CXF SecurityContext Object is created with the name and roles of the authenticated principal.

    1.2) JAASAuthenticationFeature

    Newer versions of CXF also have a CXF Feature called the JAASAuthenticationFeature. This simply wraps the JAASLoginInterceptor with default configuration for Apache Karaf. If you are deploying a CXF endpoint in Karaf, you can just add this Feature to your endpoint or Bus without any additional information, and CXF will authenticate the received credential to whatever Login Modules have been configured for the "karaf" realm in Apache Karaf.

    1.3) JAASUsernameTokenValidator

    As stated above, it is possible to validate a WS-Security UsernameToken in CXF via the JAASLoginInterceptor or the JAASAuthenticationFeature by first setting the JAX-WS property "ws-security.validate.token" to "false". This tells WSS4J to avoid validating UsernameTokens. However it is possible to also validate UsernameTokens using JAAS directly in WSS4J via the JAASUsernameTokenValidator. You can configure this validator when using WS-SecurityPolicy via the JAX-WS property "ws-security.ut.validator".

    2) Using JAAS LoginModules in Apache CXF

    Once you have decided how you are going to configure JAAS in Apache CXF, it is time to pick a JAAS LoginModule that is appropriate for your authentication requirements. Here are some examples of LoginModules you can use.

    2.1) Validating a Username + Password to LDAP / Active Directory

    For validating a Username + Password to an LDAP / Active Directory backend, use one of the following login modules:
    • Example here (context name "sun").
    • Example here (context name "jetty"). Available via the org.eclipse.jetty/jetty-plus dependency. This login module is useful as it's easy to retrieve roles associated with the authenticated user.
    2.2) Validating a Kerberos token

    Kerberos tokens can be validated via:
    • Example here.
    2.3) Apache Karaf specific LoginModules

    Apache Karaf contains some LoginModules that can be used when deploying your application in Karaf:
    • Authenticates Username + Passwords and retrieves roles via "etc/".
    • Authenticates SSH keys and retrieves roles via "etc/".
    • Authenticates Username + Passwords and retrieves roles via the OSGi Config Admin service.
    • Authenticates Username + Passwords and retrieves roles from an LDAP backend.
    •  Authenticates Username + Passwords and retrieves roles from a database.
    • Authenticates Username + Passwords and retrieves roles via the Apache Syncope IdM.
    See Jean-Baptiste Onofré's excellent blog for a description of how to set up and test the SyncopeLoginModule. Note that it is also possible to use this LoginModule in other containers, see here for an example.
    Categories: Colm O hEigeartaigh

    New Apache WSS4J releases

    Colm O hEigeartaigh - Thu, 10/09/2014 - 11:46
    Apache WSS4J 1.6.17 and 2.0.2 have been released. WSS4J 2.0.2 picks up some bug fixes via Apache Santuario and BouncyCastle dependency upgrades, in particular the latter upgrade fixes some Kerberos issues. Both releases contain some changes to how SAML tokens are processed that will be described in a forthcoming blog post.

    I also added a new Security Advisories page to the WSS4J website. For the moment it just contains some links and information on downstream security advisories that might be relevant to users of WSS4J.
    Categories: 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=""

    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=""

    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


    Subscribe to Talend Community Coders aggregator - Colm O hEigeartaigh