Apache CXF Fediz 1.2.0 tutorial - overview

Apache CXF Fediz 1.2.0 has been released. Fediz is a subproject of the Apache CXF web services stack. It is an implementation of the WS-Federation Passive Requestor Profile for SSO that supports Claims Based Access Control. In laymans terms, Fediz allows you to implement Single Sign On (SSO) for your web application, by redirecting the client browser to an Identity Provider (IdP), where the client is authenticated and redirected back to the application. Fediz consists of a number of container-specific plugins (Tomcat, Jetty, Spring Security, Websphere, etc.) as well as an IdP which bundles the CXF Security Token Service (STS) to issue SAML Tokens.

This is an overview of a planned series of articles on the new features that are available in Fediz 1.2.0, which is a new major release of the project. Subsequent articles will go into more detail on the new features, which are as follows:

• Dependency update to use CXF 3.0.x (3.0.4).
• A new container-independent CXF-based plugin is available.
• Logout Support has been added to the plugins and IdP
• A new REST API is available for configuring the IdP
• Support for authenticating to the IdP using Kerberos has been added
• Support for authenticating to the IdP using a client certificate has been added
• It is now possible to use the IdP as an identity broker with a SAML SSO IdP
• Metadata support has been added for the plugins and IdP

SAML SSO RP Metadata support in Apache CXF

Apache CXF provides comprehensive support for SSO using the SAML Web SSO profile for CXF-based JAX-RS services. In Apache CXF 3.1.0 (and 3.0.5), a new Metadata service is available to allow for the publishing of SAML SSO Metadata for a given service.

The MetadataService class is available on a "metadata" path and provides a single @GET method that returns the service metadata in XML format. It has the following properties which should be configured:

• String serviceAddress - The URL of the service
• String assertionConsumerServiceAddress - The URL of the RACS. If it is co-located with the service, then it can be the same URL as for the serviceAddress.
• String logoutServiceAddress - The URL of the logout service (if available).
• boolean addEndpointAddressToContext - Whether to add the full endpoint address to the values configured above. The default is false.

In addition, the MetadataService extends the AbstractSSOSpHandler, which contains various properties that are required to sign the metadata (keystore alias, crypto properties file which references the keystore, etc.). A sample spring-based configuration for the MetadataService is available in the CXF system tests here. Here is the sample output when accessed via a web brower:

Apache CXF 3.1.0 released

Apache CXF 3.1.0 has been released and is available for download. The migration guide for CXF 3.1.x is available here. The main (non-security) features of CXF 3.1.0 are as follows:

• Java 6 is no longer supported.
• Jetty 9 is now supported. Support for Jetty 7 has been dropped.
• A new Metrics feature for collecting metrics about CXF services is available. 
• A new Throttling feature is available for easily throttling CXF services.
• A new Logging feature is available that is more powerful than the existing logging functionality.

The security-specific changes and features are as follows:

• CXF 3.1.0 picks up a new major release of WSS4J (2.1.0) and OpenSAML (3.1.0). Please see a recent post on WSS4J 2.1.0 for some migration notes if you are using WS-Security or SAML with CXF.
• The STS now signs issued SAML tokens by default using RSA-SHA256 (previously RSA-SHA1).
• Some security configuration tags have been renamed from "ws-security.*" to "security.*", as they are now shared with the XML Security JAX-RS module. The old tags will continue to work as before however without any change. See the Security Configuration page for more information.
• The SAML/XACML functionality previously available in the cxf-rt-security module is now in a new cxf-rt-security-saml module.
• A new Metadata service for SAML SSO is available. More on this in a future blog post.
• It is now possible to "plug in" custom security policy validators for WS-Security in CXF, if you want to change the default validation logic. See here for a test that shows how to do this.

Apache WSS4J 2.0.4 released

In addition to the new major release of Apache WSS4J (2.1.0), there is a new bug fix release available - Apache WSS4J 2.0.4. Here are the most important bugs that were fixed in this release:

• We now support the InclusiveC14N policy.
• We can enforce that a Timestamp has an "Expires" Element via configuration, if desired.
• There is a slight modification to how we cache signed Timestamps, to allow for the scenario of two Signatures in a security header that sign the same Timestamp, but with different keys.
• The policy layer now allows a SupportingToken policy to have more than one token.
• A bug has been fixed in the MerlinDevice crypto provider, which is designed to work with smartcards.
• A bug has been fixed in terms of using the correct JCE provider for encryption/decryption.

Apache WSS4J 2.1.0 released

A new major release of Apache WSS4J, 2.1.0, has been released. The previous major release of almost a year ago, Apache WSS4J 2.0.0, had a lot of substantial changes (see the migration guide), such as a new set of maven modules, a new streaming implementation, changes to configuration tags, package changes for CallbackHandlers, etc. In contrast, WSS4J 2.1.0 has a much smaller set of changes, and users should be able to upgrade with very few changes (if at all). This post briefly covers the new features and migration issues for WSS4J 2.1.0.

Here are the new features of WSS4J 2.1.0:

• JDK7 minimum requirement: WSS4J 2.1.0 requires at least JDK7. The project source has also been updated to make use of some of the new features of JDK7, such as try-with-resources, etc.
• OpenSAML 3.x support: WSS4J 2.1.0 upgrades from OpenSAML 2.x to 3.x (currently 3.1.0). This is an important upgrade, as OpenSAML 2.x is not currently supported.
• Extensive code refactoring. A lot of work was done to make the retrieval of security results easier and faster.

Here are the migration issues in WSS4J 2.1.0:

• Due to the OpenSAML 3.x upgrade, you will need to make a small change in your SAML CallbackHandlers, if you are specifying the "Version". In WSS4J 2.0.x, you could specify the SAML Version by passing a "org.opensaml.common.SAMLVersion" instance through to the SAMLCallback.setSamlVersion(...) method. The "org.opensaml.common" package is removed in OpenSAML 3.x. Instead, a new Version bean is provided in WSS4J 2.1.0, that can be passed to the setSamlVersion method on SAMLCallback as before. See here for an example.
• The Xerces and xml-apis dependencies in the DOM code of Apache WSS4J 2.1.0 have been removed (previously they were at "provided" scope).
• If you have a custom Processor instance to process a token in the security header in some custom way, you must add the WSSecurityEngineResult that is generated by the processing, to the WSDocInfo Object via the "addResult" method. Otherwise, it will not be available when security results are retrieved and processed.