Support for Jetty 9 in Apache CXF Fediz 1.3.0

Yesterday I gave a tutorial on how to deploy the Apache CXF Fediz simpleWebapp example to Jetty 8 using Fediz 1.2.1. Apache CXF Fediz 1.3.0 will ship with a new plugin to support Jetty 9. In this post I will cover how to deploy the simpleWebapp example to Jetty 9 using this new plugin.

1) Deploying the 1.2.0 Fediz IdP in Apache Tomcat

As per the previous tutorial on deploying to Tomcat, we will deploy the IdP and STS in Apache Tomcat. Download Fediz and extract it to a new directory (${fediz.home}). To deploy the IdP to Tomcat:

• Copy ${fediz.home}/idp/war/* to ${catalina.home}/webapps
• Download and copy the hsqldb jar (e.g. hsqldb-1.8.0.10.jar) to ${catalina.home}/lib
• Copy idp-ssl-key.jks and idp-ssl-trust.jks from ${fediz.home}/examples/samplekeys to ${catalina.home}.
• Edit ${catalina.home}/conf/server.xml and change the ports from 8080 -> 9080 + 8443 -> 9443 so as not to conflict with Jetty.
• Edit the TLS Connector in ${catalina.home}/conf/server.xml' as well, e.g.: <Connector port="9443" protocol="org.apache.coyote.http11.Http11Protocol" maxThreads="150" SSLEnabled="true" scheme="https" secure="true" clientAuth="want" sslProtocol="TLS" keystoreFile="idp-ssl-key.jks" keystorePass="tompass" keyPass="tompass" truststoreFile="idp-ssl-trust.jks" truststorePass="ispass" />

Now start Tomcat, and check that the IdP is live by opening the STS WSDL in a web browser: 'https://localhost:9443/fediz-idp-sts/REALMA/STSServiceTransport?wsdl'

2) Deploying the simpleWebapp in Jetty 9

Download Jetty 9 and extract it to a new directory (${jetty.home}). First let's set up TLS:

• Copy ${fediz.home}/examples/samplekeys/rp-ssl-key.jks to ${jetty.home}/etc
• Copy ${fediz.home}/examples/samplekeys/ststrust.jks to ${jetty.home} *and* to ${jetty.home}/etc
• Edit ${jetty.home}/start.ini to include the ssl, https and fediz modules, and set up the TLS configuration as follows:

•  The "fediz" module referred to above must be placed in ${jetty.home}/modules/fediz.mod with content:

Now we will deploy the simpleWebapp:

• Copy ${fediz.home}/examples/simpleWebapp/src/main/config/fediz_config.xml to ${jetty.home}/etc
• Do a "mvn clean install" in ${fediz.home}/examples/simpleWebapp
• Copy ${fediz.home}/examples/simpleWebapp/target/fedizhelloworld.war to ${jetty.home}/webapps
• Create a new directory: ${jetty.home}/lib/fediz
• Copy ${fediz.home}/plugins/jetty9/lib/* to ${jetty.home}/lib/fediz (note you may want to copy in a slf4j logging binding in here to see logging output, e.g. slf4j-jdk14-1.7.12.jar).
• Create a new file in ${jetty.home}/webapps called "fedizhelloworld.xml" with content as follows, and then start Jetty as normal: 

3) 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.

Deploying the Apache CXF Fediz simpleWebapp to Jetty

On previous tutorials about Apache CXF Fediz, I have always described deploying the simpleWebapp example that ships with Fediz in Apache Tomcat. However, Fediz also supports deploying secured applications in Jetty (7 and 8 as of yet, support for Jetty 9 is forthcoming). As it can be somewhat confusing setting up the security requirements correctly, I will cover briefly how to deploy the simpleWebapp in Jetty 8 in this blog post (see the Fediz wiki for a dedicated page on deploying to Jetty).

1) Deploying the 1.2.0 Fediz IdP in Apache Tomcat

As per the previous tutorial on deploying to Tomcat, we will deploy the IdP and STS in Apache Tomcat. Download Fediz 1.2.1 and extract it to a new directory (${fediz.home}). To deploy the IdP to Tomcat:

• Copy ${fediz.home}/idp/war/* to ${catalina.home}/webapps
• Download and copy the hsqldb jar (e.g. hsqldb-1.8.0.10.jar) to ${catalina.home}/lib
• Copy idp-ssl-key.jks and idp-ssl-trust.jks from ${fediz.home}/examples/samplekeys to ${catalina.home}.
• Edit ${catalina.home}/conf/server.xml and change the ports from 8080 -> 9080 + 8443 -> 9443 so as not to conflict with Jetty.
• Edit the TLS Connector in ${catalina.home}/conf/server.xml' as well, e.g.: <Connector port="9443" protocol="org.apache.coyote.http11.Http11Protocol" maxThreads="150" SSLEnabled="true" scheme="https" secure="true" clientAuth="want" sslProtocol="TLS" keystoreFile="idp-ssl-key.jks" keystorePass="tompass" keyPass="tompass" truststoreFile="idp-ssl-trust.jks" truststorePass="ispass" />

Now start Tomcat, and check that the IdP is live by opening the STS WSDL in a web browser: 'https://localhost:9443/fediz-idp-sts/REALMA/STSServiceTransport?wsdl'

2) Deploying the simpleWebapp in Jetty 8

Download Jetty 8 and extract it to a new directory (${jetty.home}). First let's set up TLS:

• Copy ${fediz.home}/examples/samplekeys/rp-ssl-key.jks to ${jetty.home}/etc
• Copy ${fediz.home}/examples/samplekeys/ststrust.jks to ${jetty.home} *and* to ${jetty.home}/etc
• Edit ${jetty.home}/start.ini and make sure that 'etc/jetty-ssl.xml' is included.
• Edit ${jetty.home}/etc/jetty-ssl.xml and configure the TLS keys, e.g.:

Now we will deploy the simpleWebapp:

• Copy ${fediz.home}/examples/simpleWebapp/src/main/config/fediz_config.xml to ${jetty.home}/etc
• Do a "mvn clean install" in ${fediz.home}/examples/simpleWebapp
• Copy ${fediz.home}/examples/simpleWebapp/target/fedizhelloworld.war to ${jetty.home}/webapps
• Create a new directory: ${jetty.home}/lib/fediz
• Copy ${fediz.home}/plugins/jetty/lib/* to ${jetty.home}/lib/fediz (note you may want to copy in a slf4j logging binding in here to see logging output, e.g. slf4j-jdk14-1.7.12.jar).
• Edit ${jetty.home}/start.ini and add "fediz" to "OPTIONS".
• Create a new file in ${jetty.home}/contexts called "fedizhelloworld.xml" with content as follows, and then start Jetty as normal:

3) 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.

Authorization for web services using XACML 3.0

In a blog post last year, I covered some authentication and authorization test-cases for Apache CXF-based web services that I uploaded to github. In particular, the cxf-sts-xacml demo showed how a CXF service can use XACML to authorize a web service request, by sending a XACML request to a Policy Decision Point (PDP) and then by enforcing the authorization decision. This demo only covered XACML 2.0 (provided by OpenSAML). In this post we will give an example of how to use XACML 3.0 via Apache OpenAz to make and enforce authorization requests for Apache CXF based services.

1) Introducing Apache OpenAz

The XACML functionality in Apache CXF is based on OpenSAML, which provides support for XACML 2.0. However, XACML 3.0 is an OASIS standard as of January, 2013. A new project in the Apache Incubator called Apache OpenAz addresses this gap. The source code is broken down into the following modules:

• openaz-xacml - API + common functionality.
• openaz-xacml-rest - Some common functionality used by the RESTful API interfaces
• openaz-xacml-pdp - A PDP implementation
• openaz-xacml-pdp-rest - An implementation of the XACML 3.0 RESTful Interface for the PDP
• openaz-xacml-pap-rest - An implementation of the XACML 3.0 RESTful Interface for the PAP
• openaz-xacml-test - Some testsuites
• openax-pep -  The PEP (Policy Enforcement Point) implementation.

2) Integrating Apache OpenAz with Apache CXF

The testcases are available here:

• cxf-sts-xacml: This project contains a number of tests that show how to use XACML with CXF to authorize a client request. It contains both XACML 2.0 tests and XACML 3.0 tests.

In both cases, the client obtains a SAML Token from the STS with the roles of the client embedded in the token. The service provider extracts the roles, and creates a XACML request. For the XACML 2.0 case, OpenSAML is used to create a XML XACML 2.0 request. This is then sent to a mocked PDP JAX-RS service. However, let's focus on the XACML 3.0 case. In this test, the OpenAz API (via the openaz-xacml module as covered above) is used to create a JSON XACML 3.0 request. This is evaluated by a OpenAz-based PDP which is co-located with the service. After evaluating the request, the PDP response is then enforced at the service side.

The service endpoint is configured in Spring as follows, registering a XACML3AuthorizingInterceptor (which in turn contains a reference to the co-located PDP):

The XACML3AuthorizingInterceptor is configured with a implementation to create a XACML 3.0 request using the SAML 2.0 profile of XACML 3.0, which is subsequently converted into JSON + sent to the PDP. The PDP is configured with "root" and "reference" policies, that state that a user of role "boss" has permission to "execute" the Web Service Operation "{http://www.example.org/contract/DoubleIt}DoubleItService#DoubleIt". For example:

A sample authorization request looks like:

If you are interested in XACML 3.0 please get involved with the Apache OpenAz project! Once the project gets more mature, the PEP code in my project will probably make it over to Apache CXF so that users have the option of supporting XACML 2.0 or 3.0 (and XML or JSON) with their web services.