Thursday, July 3, 2014

New Apache Santuario releases

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

Friday, June 20, 2014

Apache CXF Fediz 1.1.1 released

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

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

1) Fediz example

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

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

a) Deploying the IdP/STS

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

b) Deploying the service

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

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

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

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

Thursday, May 29, 2014

Apache CXF Authentication and Authorization test-cases II

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

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

Wednesday, May 21, 2014

Apache CXF 3.0.0 released

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

Wednesday, May 7, 2014

Apache WSS4J 2.0.0 released

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

Tuesday, May 6, 2014

Apache Santuario - XML Security for Java 2.0.0

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

Apache WSS4J 2.0.0 - part VIII

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

1) Streaming WS-Security functionality via WS-SecurityPolicy

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

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

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