Latest Activity

Amazon EC2 Plugin Release 1.30

Francis Upton's blog - Tue, 01/12/2016 - 16:24

I have just finished a bunch of work on this plugin to fix a number of bugs related to starting instances and respecting instance caps for spot instances. The plugin will now restart a stopped instance and always respect the instance caps. Other issues about the credentials working correctly in all regions should be fixed.

Before I make this release, I would like to have people test with the 1.30 Snapshot to see if there are any problems. Once this release is done, I will take some new features and move to require a more recent version of Jenkins.

Categories: Francis Upton

Understanding Spring Web-Flow in Apache Fediz - Part 1

Jan Bernhardt - Thu, 01/07/2016 - 16:20
When I started to work with Apache Fediz, most of the actions looked like magic to me, because I was not able to understand how Spring Security and Spring Web Flow have been used in Apache Fediz. After several hours of learning and investigation I finally understood how all this works together.

In this post I would like to share with you from what I understood of how Fediz works internally.
When you take a look inside the WEB-INF/web.xml you will find three URL mappings:
  • /services/* provides access to all REST services for updating the IDP configuration
  • /FederationMetadata/2007-06/FederationMetadata.xml provides access to the generated IDP metadata document which is usually used in application wizards to setup the correct IDP configuration
  • /federation provides access to the configured Spring Web-Flow

If you take a look inside the WEB-INF/web.xml you will see that the /federation URL is linked with org.springframework.web.servlet.DispatcherServlet. The initialization of the Spring Flow however takes place within the WEB-INF/idp-servlet.xml.
So how is the DispatcherServlet linked to the idp-servlet.xml?
The key to the answer is Spring MVC which uses Convention over Configuration (CoC). Spring will search for a file with the same name as the servlet-name and ending with "-servlet.xml". To apply this knowledge you can see that the /federation URL is mapped to the servlet name idp and thus the default configuration spring file which will be loaded from the DispatcherServlet is idp-servlet.xml
Spring ConfigurationWithin the idp-servlet.xml you will find a spring configuration to setup the Spring Web Flow.
First Spring will do a component scan to instantiate and autowire all beans with a @Component annotation located within the beans package. These beans usually provide specific actions which are executed within the flows.
<context:component-scan base-package="org.apache.cxf.fediz.service.idp.beans" />
Now the JSP views and HTML resources like images will be made available for the spring web flow:
<mvc:resources mapping="/images/**" location="/resources/images/" />
<mvc:view-controller path="/" view-name="index" />
<mvc:view-controller path="/federation/up/login" view-name="signinform" />

<bean id="viewResolver"
<property name="prefix" value="/WEB-INF/views/" />
<property name="suffix" value=".jsp" />

<bean id="viewFactoryCreator"
<property name="viewResolvers">
<ref local="viewResolver" />

<bean id="expressionParser"
class="org.springframework.webflow.expression.WebFlowOgnlExpressionParser" />

<webflow:flow-builder-services id="builder"
view-factory-creator="viewFactoryCreator" expression-parser="expressionParser" />
At next the actual spring web flows will get registered. All beans setup within this spring config will be available within the web flows.
<webflow:flow-registry id="flowRegistry"
        path="/WEB-INF/flows/federation-validate-request.xml" id="federation" />
        path="/WEB-INF/flows/federation-validate-request.xml" id="federation/up" />
        path="/WEB-INF/flows/federation-validate-request.xml" id="federation/krb" />
        path="/WEB-INF/flows/federation-validate-request.xml" id="federation/clientcert" />
        path="/WEB-INF/flows/federation-signin-request.xml" id="signinRequest" />
        path="/WEB-INF/flows/federation-signin-response.xml" id="signinResponse" />
Adding security restrictions to the flow will allow spring security to be included in the flow for user authentication.
<bean class="org.springframework.webflow.mvc.servlet.FlowHandlerMapping" p:flowRegistry-ref="flowRegistry"

<webflow:flow-executor id="flowExecutor" flow-registry="flowRegistry">
        <webflow:always-redirect-on-pause value="false" />

        <webflow:listener ref="securityFlowExecutionListener" />

<bean class="org.springframework.webflow.mvc.servlet.FlowHandlerAdapter" p:flowExecutor-ref="flowExecutor" />

<bean id="securityFlowExecutionListener" class="">
    <property name="accessDecisionManager" ref="accessDecisionManager" />

<bean id="accessDecisionManager" class="">
    <property name="decisionVoters">
            <bean class="">
                <property name="rolePrefix" value="ROLE_" />
            <bean class="" />
The spring security configuration can be found within the WEB-INF/security-config.xml file.
Categories: Jan Bernhardt

Register trusted 3rd party IDP with SAML Web Browser SSO Profile

Jan Bernhardt - Fri, 12/18/2015 - 23:35
In this Post I'll explain how to configure Apache Fediz IDP so that it can be used with a trusted 3rd party IDP based on SAML Web Browser SSO Profile.

In my previous posts about Apache Fediz I focused on the WS-Federation passive protocol only since it is the successor standard for the SAML Web Browser SSO Profile. But in some cases you will have to establish a federated trust relation with an IDP how does not support the WS-Federation Standard yet, but only the older SAML Web Browser SSO Profile.

I'll explain how to register a SAML trusted IDP at the IDP as well as how to setup a demonstrator. Please also take a look at Colms post about this topic. PreconditionsI would assume that you have the fedizhelloworld demo application already running within your Tomcat container, as well as the Fediz IDP & STS in a second Tomcat  container. If you don't know how to do this, you will find a detailed instruction in my previous post about Fediz, as well as this post from Colm.
Install SAML IDPFediz IDP itself does not support the SAML Web Browser Profile as a primary IDP protocol. So you cannot use Fediz IDP so login based on SAML Web Browser Profile. But you can register a 3rd party IDP based on that profile when Fediz is acting as a Service Provider (client).

For purposes of integration testing however the Fediz Project provides a mockup implementation of a SAML IDP which we will use for demonstration purposes here. To build the war file you should do the following:

1. Clone the Fediz Sources on your computer with GIT
> git clone -v
2. Goto the systestfolder and build the systest with maven
> cd cxf-fediz/systests/federation/samlIdpWebapp/
> mvn -Pfastinstall
3. Copy war file to tomcat webapps folder
> cp target/*.war ${tomcat.fediz.idp.home}/webapps
4. Start Fediz-IDP and Fediz Demo app (if not already done yet)
> ${tomcat.fediz.idp.home}/bin/
> ${tomcat.fediz.rp.home}/bin/ Register 3rd Party IDPNext you must register the SAML SSO IDP at your Fediz-IDP so that you can choose it as your home realm at the login process. This can be done via a REST API since version 1.2.0.

The REST Service API requires a Basic user authentication. Default username is admin and password is password.
1. Register a new 3rd Party IDP
POST https://localhost:9443/fediz-idp/services/rs/trusted-idps
<ns2:trustedIdp id="0" xmlns:ns2="http://org.apache.cxf.fediz/">
   <name>Realm C</name>
   <description>SAML Web SSO</description>
</ns2:trustedIdp>2. Assign this new 3rd Party IDP to your Realm-A Fediz IDP
POST https://localhost:9443/fediz-idp/services/rs/idps/urn%3Aorg%3Aapache%3Acxf%3Afediz%3Aidp%3Arealm-A/trusted-idps
<ns2:trustedIdp xmlns:ns2="http://org.apache.cxf.fediz/">
</ns2:trustedIdp> Test: Perform a federated Login
Make sure to delete any localhost cookies within your browser. Otherwise your preferred home realm could be stored within a cookie and therefore your would not see a home realm selection screen.
Now you can perform a login by invoking the following URL:

You should see a home realm selection screen, with our new SAML SSO IDP which you should select. Next you should see a Basic user authentication window. Here you can login with ALICE and ECILA as your password.

After some redirect you should see the demo page with your federated user account from alice:

Review Redirects in DetailIf you use a monitoring tool like Fiddler, you will be able to analyze the redirects in greater detail.

After invoking the fedizhelloworld demo app, I'll get redirected to the Fediz IDP:
GET https://localhost:9443/fediz-idp/federation
The Fediz IDP will show you the home realm selection page and after selection will redirect you to the SAML SSO IDP
GET https://localhost:9443/samlssoidp/samlsso
You can use for example Notepad++ to decode SAML-P Requests & Responses.

After decoding the SAMLRequest you will see the following SAML AuthnRequest:
<saml2p:AuthnRequest AssertionConsumerServiceURL="https://localhost:9443/fediz-idp/federation" Destination="https://localhost:9443/samlssoidp/samlsso" ForceAuthn="false" ID="c7f0b64a-f330-4816-9974-061d9ab4da01" IsPassive="false" IssueInstant="2015-12-18T17:45:39.791Z" ProtocolBinding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST" Version="2.0" xmlns:saml2p="urn:oasis:names:tc:SAML:2.0:protocol">
    <saml2:Issuer xmlns:saml2="urn:oasis:names:tc:SAML:2.0:assertion">urn:org:apache:cxf:fediz:idp:realm-A</saml2:Issuer>
    <saml2p:NameIDPolicy AllowCreate="true" Format="urn:oasis:names:tc:SAML:2.0:nameid-format:persistent" SPNameQualifier="urn:org:apache:cxf:fediz:idp:realm-A"/>
    <saml2p:RequestedAuthnContext Comparison="exact">
        <saml2:AuthnContextClassRef xmlns:saml2="urn:oasis:names:tc:SAML:2.0:assertion">urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport</saml2:AuthnContextClassRef>

After login at the SAML IDP the user will be redirected back to Fediz-IDP:
GET https://localhost:9443/fediz-idp/federation
    &RelayState=962c9908-489c-4ea2-b1a4-090e180c91f3Usually you would receive a POST message from the SAML IDP instead of a GET redirect, as done here by the mockup IDP.
A decoded SAMLResponse will look like this:
<saml2p:Response ID="1772f107-14b9-4d27-9d21-f3a1cf655648" InResponseTo="41e5c1dc-7cfe-446e-b475-3fb7a40b5432" IssueInstant="2015-12-18T14:16:24.456Z" Version="2.0" xmlns:saml2p="urn:oasis:names:tc:SAML:2.0:protocol">
    <saml2:Issuer xmlns:saml2="urn:oasis:names:tc:SAML:2.0:assertion">https://localhost:9443/samlssoidp/samlsso</saml2:Issuer>
        <saml2p:StatusCode Value="urn:oasis:names:tc:SAML:2.0:status:Success"/>
    <saml2:Assertion ID="_42311918-c677-4773-86b7-e5b42340354d" IssueInstant="2015-12-18T14:16:24.456Z" Version="2.0" xmlns:saml2="urn:oasis:names:tc:SAML:2.0:assertion" xmlns:xsi="" xsi:type="saml2:AssertionType">
        <ds:Signature xmlns:ds="">
                <ds:CanonicalizationMethod Algorithm=""/>
                <ds:SignatureMethod Algorithm=""/>
                <ds:Reference URI="#_42311918-c677-4773-86b7-e5b42340354d">
                        <ds:Transform Algorithm=""/>
                        <ds:Transform Algorithm=""/>
                    <ds:DigestMethod Algorithm=""/>
            <saml2:NameID Format="urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified">ALICE</saml2:NameID>
            <saml2:SubjectConfirmation Method="urn:oasis:names:tc:SAML:2.0:cm:bearer">
                <saml2:SubjectConfirmationData Address="" InResponseTo="41e5c1dc-7cfe-446e-b475-3fb7a40b5432" NotOnOrAfter="2015-12-18T14:21:24.456Z" Recipient="https://localhost:9443/fediz-idp/federation"/>
        <saml2:Conditions NotBefore="2015-12-18T14:16:24.456Z" NotOnOrAfter="2015-12-18T14:21:24.456Z">
        <saml2:AuthnStatement AuthnInstant="2015-12-18T14:16:24.456Z">

Fediz-IDP is configured to do a identity mapping and will return a SAML token back to the demo application according to WS-Federation.
POST https://localhost:8443/fedizhelloworld/secure/fedservlet

The final wresult which will be sent to the demo app looks like this:
<RequestSecurityTokenResponseCollection xmlns="" xmlns:ns2="" xmlns:ns3="" xmlns:ns4="" xmlns:ns5="">
<saml2:Assertion xmlns:saml2="urn:oasis:names:tc:SAML:2.0:assertion" xmlns:xsd="" xmlns:xsi="" ID="_d11b7fa4-3dc2-4b81-a29e-c80cc6e20436" IssueInstant="2015-12-18T17:45:39.933Z" Version="2.0" xsi:type="saml2:AssertionType">
<saml2:Issuer>STS Realm A</saml2:Issuer>
<ds:Signature xmlns:ds="">
<ds:CanonicalizationMethod Algorithm=""/>
<ds:SignatureMethod Algorithm=""/>
<ds:Reference URI="#_d11b7fa4-3dc2-4b81-a29e-c80cc6e20436">
<ds:Transform Algorithm=""/>
<ds:Transform Algorithm="">
<ec:InclusiveNamespaces xmlns:ec="" PrefixList="xsd"/>
<ds:DigestMethod Algorithm=""/>
<saml2:NameID Format="urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified" NameQualifier="">alice</saml2:NameID>
<saml2:SubjectConfirmation Method="urn:oasis:names:tc:SAML:2.0:cm:bearer"/>
<saml2:Conditions NotBefore="2015-12-18T17:45:39.890Z" NotOnOrAfter="2015-12-18T18:45:39.890Z">
<saml2:Attribute Name="" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:unspecified">
<saml2:AttributeValue xsi:type="xsd:string">User</saml2:AttributeValue>
<saml2:Attribute Name="" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:unspecified">
<saml2:AttributeValue xsi:type="xsd:string">Alice</saml2:AttributeValue>
<saml2:Attribute Name="" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:unspecified">
<saml2:AttributeValue xsi:type="xsd:string">Smith</saml2:AttributeValue>
<saml2:Attribute Name="" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:unspecified">
<saml2:AttributeValue xsi:type="xsd:string"></saml2:AttributeValue>
<ns4:SecurityTokenReference xmlns:wsse11="" wsse11:TokenType="">
<ns4:KeyIdentifier ValueType="">_d11b7fa4-3dc2-4b81-a29e-c80cc6e20436</ns4:KeyIdentifier>
<ns4:SecurityTokenReference xmlns:wsse11="" wsse11:TokenType="">
<ns4:KeyIdentifier ValueType="">_d11b7fa4-3dc2-4b81-a29e-c80cc6e20436</ns4:KeyIdentifier>
<wsp:AppliesTo xmlns:wsp="" xmlns:wst="">
<wsa:EndpointReference xmlns:wsa="">

Categories: Jan Bernhardt

Liferay Portal Integration with Fediz OpenID Connect

Jan Bernhardt - Thu, 12/17/2015 - 11:24
I was given the task to provide a security solution to enable SSO in a Liferay portal based on OpenID Connect with the Apache Fediz OIDC Service. In this post I'll explain how to get this done.

You will need Apache Fediz version 1.3.0 or higher, if you want to setup this use case by yourselfInstall Liferay Portal with Fediz PluginFirst download and extract Liferay bundled with Tomcat. (I used liferay-portal-6.2-ce-ga5)

Enable HTTPs port in liferay-portal-6.2-ce-ga5/tomcat-7.0.62/conf/server.xml
<Server port="8005" shutdown="SHUTDOWN">

     . . .

    <Service name="Catalina">

         . . .

        <Connector port="8443" protocol="org.apache.coyote.http11.Http11Protocol"
             maxThreads="150" SSLEnabled="true" scheme="https" secure="true"
             sslProtocol="TLS" />

I reused the idp-ssl-key.jks file from the IDP Tomcat to keep things simple. Of course you can also use a different keystore. Your keystore should be stored in your tomcat root folder liferay-portal-6.2-ce-ga5/tomcat-7.0.62/.

Now you can start Liferay for a first setup. Simply execute liferay-portal-6.2-ce-ga5/tomcat-7.0.62/bin/

After Tomcat startup is complete you can invoke the server page at https://localhost:8443/.

I continued with the default values (except for the Email address) and simply clicked "Finish Configuration". After that you have to wait until Liferay installation is complete. Next you will see the license confirmation page, which you need to confirm. After that you can set your password reminder as well as the administration password.

The OpenID Connect Extension which we will install in the following section requires a user group UnityUser which will be applied for all new users when then login the very first time to the portal. Therefore we must create this user group first under control panel -> Users -> User Groups -> Add

Your Liferay Portal is now up and running so lets continue next on enabling OpenID Connect for your portal.
Register Liferay Portal at OIDC ProviderAfter starting your OIDC Service, you can register the Liferay Portal under the following URL: https://localhost:9443/fediz-oidc/clients/register.

You will need the client Identifier as well as the Client Secret in the following section.
Install OpenIdConnect Extension for LiferayYou will need the OpenIdConnectLiferay extension, which you can clone from Github. Further information on installing this extension can be found at the authors webpage.

You'll need to update the configuration within

public Authenticator(State state) {
    authC = new ClientSecretBasic(new ClientID("hLiSIY6b1X_0Jg"), new Secret("llPySiI1aEwyIgsnyBu6aA"));
    this.state = state;
    try {
        callback = new URI("https://localhost:8443/c/portal/login");
oauthS = new URI("https://localhost:9443/fediz-oidc/idp/authorize");
        tokenS = new URI("https://localhost:9443/fediz-oidc/oauth2/token");
        userS = new URI("https://localhost:9443/fediz-oidc/users/userinfo");
        tokenCertSign = new URI("https://localhost:9443/fediz-oidc/jwk/keys");
        issuer = "";
        aud = "hLiSIY6b1X_0Jg";
    } catch (URISyntaxException ex) {

Now you can build and deploy this extension.
$ mvn clean install
You will find a jar file with all extensions at OpenIdConnectLiferay/target/OpenIdConnectLiferay-0.1-jar-with-dependencies.jar. You need to copy this jar file to liferay-portal-6.2-ce-ga5/tomcat-7.0.62/lib/ext/.

Next you need to create (or modify if it already exists) the following file liferay-portal-6.2-ce-ga5/tomcat-7.0.62/webapps/ROOT/WEB-INF/classes/ to activate the OpenID Connect Login handler:

Now you should restart your tomcat and after that you can invoke the following login URL: https://localhost:8443/c/portal/login?openIdLogin=true. This time you should get redirected to Fediz-IDP for user authentication (login). After successful login you should be able to see your portal again with an active user.

For debugging purposes is can also be helpful to increase the log level by adding the following line at liferay-portal-6.2-ce-ga5/tomcat-7.0.62/conf/ = FINE
Test your Setup: Login with OpenID ConnectNow you can validate if your setup is working as expected. Open the following URL in your browser:

Make sure to logout first, if you are still logged in at your portal.
You should get redirected to the Fediz IDP Login page and after login (bob:bob) you should get redirected back to your Liferay portal.
When you login the very first time, you should see a screen to confirm the "Terms of Use". After that you will be asked to enter a new password. This password can be used to login without SSO / OpenID Connect so you should choose a complex password. As long as you use SSO however you will never be ask again to enter this password. Same applies to the password reminder.
Once that is done, you will see the start screen of the Liferay Portal.
Now you can logout and login again with the above URL. This time you will login directly without any additional steps/questions.

You have been successful!
Categories: Jan Bernhardt

Fediz with OpenID Connect Support and WS-Federation Bridge (2/2)

Jan Bernhardt - Mon, 12/14/2015 - 14:46
Setup a DemonstratorIn this article I'll explain how to setup a demonstrator for the use case described in my previous post.
Setup Fediz IDP & OIDCFirst you need to setup the Fediz IDP as usual. To get the OIDC Service working you also need to do the following:
  1. Install Fediz Plugin for the Fediz IDP Server (usually you would do this for the client application only)
    For the fediz_config.xml you can use the sample provided with the OIDC Service.
  2. Download or build the OIDC service and then deploy the fediz-oidc.war file to your webapps folder (same place where you deployed STS & IDP)
Register an OpenID Connect Client From the perspective of OpenID Connect the Web Portal takes the role of a OIDC client. So the client must be registered up front. After starting the OIDC service you can invoke the following URL in your browser:

For Client Name and Client Description you can enter any human readable and meaningful value related to your service.
OIDC supports Confidential as well as Public as a Client Type. If your Client is a Public client (for example your client is java code running inside the browser of a user), no client secret will be generated, since the secret could not be protected anyway. The normal use case however should be Confidential.
Your redirect URI will be the final URL from which the OIDC service will redirect the user with the generated code. Normally this will be a OIDC Client service from your app consuming the code value and exchanging it for an access and ID token.
If your application (OIDC Client) is  bound to a fix Home Realm (all users from this app will always login at the same home realm), then you can select this HomeRealm here. In this case users will not see a home realm selection screen but will be redirected to the correct home realm IDP directly.

After submitting you client information you will see the generated client_id and client_secret. These values need to be set at the web portal.
Understanding the Web PortalYour web portal can by any kind of (java) web application. To enable OpenID Connect support at my web application I need to add a Relaying Party (RP) OIDC Handler at a URL of my choice.
OIDC RP endpoint: authenticates a user by redirecting a user to OIDC Provider, and redirects the user
to the initial application form once the authentication is done
<jaxrs:server id="oidcRpServer" address="/oidc">
<bean class="">
<!-- This state manager is shared between this RP endpoint and the oidcRpFilter which protects
the application endpoint, the RP endpoint sets an OIDC context on it and the filter checks
the context is available -->
<property name="clientTokenContextManager" ref="stateManager" />
<!-- Where to redirect to once the authentication is complete -->
<property name="defaultLocation" value="/app/service/start" />

<!-- the filter which does the actual work for obtaining an OIDC context.
It redirect to the OIDC Provider, exchanges an authorization code for access token,
extracts OIDC IdToken and makes it all available as OidcCientTokenContext
<bean id="rpOidcRequestFilter" class="">
<property name="clientCodeStateManager">
<!-- This state manager creates an OAuth2 'state' parameter and saves it in the HTTP session -->
<bean class="">
<property name="generateNonce" value="true"/>
<property name="scopes" value="openid refreshToken" />
<property name="accessTokenServiceClient" ref="atServiceClient" />
<property name="idTokenReader">
<bean class="">
<!-- disable it if the local key store or the client secret is used to validate ID Tokens -->
<property name="jwkSetClient" ref="jwkSetClient"/>
<property name="issuerId" value=""/>
<property name="consumer" ref="consumer" />
<property name="authorizationServiceUri" value="https://localhost:9443/fediz-oidc/idp/authorize" />
<property name="startUri" value="rp" />
<property name="completeUri" value="/" />

<!-- JAX-RS provider that makes OidcClientTokenContext available as JAX-RS @Context -->
<ref bean="clientTokenContextProvider" />
<!-- The state manager shared between the RP and application endpoints -->
<bean id="stateManager" class=""/>
<!-- WebClient for requesting an OAuth2 Access token.
rpOidcRequestFilter uses it to exchange a code for a token -->

<jaxrsclient:client id="atServiceClient" threadSafe="true"
<entry key="Accept" value="application/json"/>
<bean class="org.apache.cxf.jaxrs.provider.FormEncodingProvider">
<property name="expectedEncoded" value="true"/>

<!-- Client id and secret allocated by OIDC ClientRegistrationService -->
<bean id="consumer" class="">
<property name="clientId" value="-7TdKEwzkf5BSQ"/>
<property name="clientSecret" value="q6ys7349uXMIgOu1kXNFTQ"/>
<!-- JAX-RS provider that makes OidcClientTokenContext available as JAX-RS @Context -->
<bean id="clientTokenContextProvider" class=""/>

<!-- disable it if the local key store or the client secret is used to validate ID Tokens -->
<jaxrsclient:client id="jwkSetClient" threadSafe="true"
<entry key="Accept" value="application/json"/>
<bean class=""/>

For being able to use the access token when invoking a REST Backend-Service you must add the access token as an Authorization Header within your Request. For this purpose you must first create a JAX-RS Client and also inject the OIDC-Context to your application.
<jaxrsclient:client id="backendServiceClient" threadSafe="true"
   address="https://localhost:8082/backendService" serviceClass="org.apache.cxf.jaxrs.client.WebClient">
       <entry key="Accept" value="application/json"/>
      <bean class="com.fasterxml.jackson.jaxrs.json.JacksonJsonProvider"/>
Within your code you need to inject the OidcClientTokenContext, for example via @Context annotation:
private OidcClientTokenContext oidcContext;
Within your method when just before invoking the REST Service you must add the authorization header as follows:
ClientAccessToken accessToken = oidcContext.getToken();
Understanding the REST ServiceLets take a DemoService as an example to explain the OIDC/Auth2 Integration at the backend REST Service.First lets take a loog a the REST Interface. You will note an annotation @Scopes which will require that the used access token was provided for the scope userinfo. The other method will also require an access token, but without any scope enforcement.


public class DemoService {
    public String getGreeting() {
        return "Hello World!";
    public String getPersonalGreeting(@QueryParam("name") String name) {
        return "Hello " + name + "!";

Within your Spring configuration you need to add two filters. The OAuthRequestFilter is needed to ensure that the provided access token is still valid, and the OAuthScopesFilter checks that the required scope for invoking a certain method will matches with the scope of the access token.
<bean id="demoService" class="org.apache.service.DemoService"/>

<jaxrs:server id="demoService" address="/greeting">
        <ref bean="demoService"/>
        <bean class="">
         <property name="tokenValidator">
<bean class="">
         <property name="tokenValidatorClient" ref="tokenValidatorClient"/>
    <bean class="">
        <property name="securedObject" ref="demoService"/>

<jaxrsclient:client id="tokenValidatorClient"
<entry key="Content-Type" value="application/x-www-form-urlencoded"/>
<entry key="Accept" value="application/xml"/>
<bean class="org.apache.cxf.jaxrs.provider.FormEncodingProvider">
<property name="expectedEncoded" value="true"/>
Since validation is not yet standardized  the tokenValidatorClient communicates with the OIDC service in a proprietary manner.

Categories: Jan Bernhardt

Fediz with OpenID Connect Support and WS-Federation Bridge (1/2)

Jan Bernhardt - Wed, 12/09/2015 - 16:53
I'm currently engaged for a big company to provide a solution that allows this company to offer various (REST) services to their partners while these services are hosted and maintained by the company but users can login to these services with accounts managed within their own partner network.

This solution should work for Web-Portals, Mobile Apps & Desktop Applications.

First I was skeptical if it will be possible to find one solution fitting all theses different use cases. But I think I actually did find a very interesting solution. In this post I'll explain the overall architecture of this solution. In my next posts I'll tell you how to get a Liferay Web-Portal integrated as well as a mobile App based on Android.

WS-Federation normally uses SAML Tokens for user authentication. This is fine for container based security solutions, when the user wants to login to a web-portal. But modern web applications (e.g. AJAX based) tend to be executed primarily in the Browser, invoking REST backend services directly from within the Browser.
Handling XML based tokens (incl. XML signature validation) is just a too heavy burden for this type of applications. Also handling lifetime issues with SAML Token could require a Token exchange with an STS. But an STS only provides a SOAP interface according to WS-Trust. It is not feasible for a AJAX Web Application to handle SOAP communication including XML security. Browser based applications should be light-weight and thus they prefer talking to REST services.

Token Types & Token Handling JSON Web Tokens (JWT) are similar to SAML tokens but instead of being XML based they are provided in a JSON format. Since JSON is the preferred document format for REST services, they fit much better to a REST Service compared to a XML based SAML Token.

One step closer to the solution could be to provide a STS that can issue JWT tokens as well as SAML tokens. This could help to exchange SAML token to JWT token and vice versa in cases when you need both. SAML for SOAP services and JWT for REST services. Colm O hEigeartaigh has already done some improvements to the CXF STS to support JWT tokens at the STS.

Instead of requesting a SAML Token with the following TokenType you can now also request a JWT token with this TokenType urn:ietf:params:oauth:token-type:jwt.

This way you can request or even exchange JWT tokens simply by setting the expected TokenType value. When sending a SAML or JWT token OnBehalfOf your token request you can exchange one format for the other.
What is currently missing to bridge both token types for SOAP and REST scenarios would be a REST interface for the STS. This would make it a lot easier for REST clients to interact with an STS. Since there are no standards for a STS REST API, I'll design a REST interface by myself discuss it with the CXF community and then add it to the STS soon.

OpenID ConnectI would see OpenID Connect as the successor standard for WS-Federation which was the successor standard of the SAML Web-Profile. You can see that the OIDC sequence flow is still similar to the prior protocols but that it also learned and improved a lot from the older standards.

OIDC is also based on the OAuth2 standard and thus inherits also all benefits and drawbacks of this protocol.

Many big internet companies support OpenID Connect like Google, Facebook, Twitter, etc..
OpenID Connect is related but not equal to OpenID on which some of the bigger companies dropped already the support for (like Google).
Simple Sequence FlowOpenID connect is based on OAuth2 and thus provides several sequence flows. Which one you will choose will depend on your circumstances. In this blog I'll focus on the authorization code flow only.

(1) The user invokes the WebPortal (same would apply if the user invokes a REST Service).
Host: demo.portal.comto be continued...
(2) Since there is no existing session with the user, the server response with a redirect to the OIDC Server (line breaks added to improve readability).
HTTP/1.1 303 See Other
The user will see a login screen for authentication.
(3) After successful login the user will be redirected back to the provided redirect_uri with an authorization code:
HTTP/1.1 303 See Other
Set-Cookie: JSESSIONID=55638DC5FF717DD730B72978B70F088E; Path=/idp/; Secure; HttpOnly
Cache-Control: private
Expires: Thu, 01 Jan 1970 01:00:00 CET
Date: Thu, 19 Nov 2015 13:39:08 GMT
(4) This code can now be used by the service provider (web portal) to get a JWT token. For this reason the service provider needs to authenticate against the token endpoint with its client_id & client_secret within the Authorization header, as well as the code value and redirect_uri.
Authorization: Basic Um8yaEpWdGo5NG9XTHc6RUFpemlWUU5PWVpmaHN5WGlSNmpxUQ==

As a result the token endpoint of the OIDC IDP will return the JWT Token as well as an access code. The access code will not be needed in this first scenario but is just part of the usual Oauth2 flow.
HTTP/1.1 200 OK
Content-Type: application/json

"access_token": "a8de6a544738c9e9036318ee78dfe7",
"token_type": "Bearer",
"expires_in": 3600,
"scope": "openid",
"id_token": "eyJhbGciOiJSUzI1NiJ9.eyJzdWIiOiJib2IiLCJhdWQiOiJVVUY5RmRzNjdubnA2QSIsImlhdCI6MTQ0OTY3NDMyNywiZXhwIjoxNDQ5NzM0MzI3LCJnaXZlbl9uYW1lIjoiQm9iIiwiZW1haWwiOiJib2J3aW5kc29yQHJlYWxtYS5vcmciLCJmYW1pbHlfbmFtZSI6IldpbmRzb3IiLCJuYW1lIjoiQm9iIFdpbmRzb3IiLCJub25jZSI6IjFkNWM0MjhmZmJmZjNlZWQ5NTcyMTMzOWU2N2M1NmU4YzJhYTRhZGQ2YmI0OTNlNDM2MjQ5NTc4YzgxZjg4IiwiaXNzIjoiYWNjb3VudHMuZmVkaXouY29tIiwiYXRfaGFzaCI6InZvc1h4a1lhcW1aYmJiTWlVdWdYRUEifQ.VQB4QfI1nrka5cfgq8aOGyT0iv3EEE7BBETIzQHbee1t9BDr8wPNV55pGY1YqU6F5C9KIkWiIGLz8MBlKwQVfU7FfzXqm4gEF2zbq4i_LyL-f_RW38-id4VmfF3n6ybWDqdmLLXagFL2UurTdIuGWxbZVW_bgnuIc5dJfnQ_b2wi9hxoL-1u4PPufDLfTLBYRtP5zaedR01me9T5i6PCn2jZSdvfd9304Jf6MOf98Cvv-faeZ87ilUrd5k3q4tQl6dIL3IefPBTfbR8Ni69viD29A-PvtKLquQcGp6p3NEXnwOYF7c72ZsjuZI2pcItoeBeo2Whz9Ni21vfWsd3Iaw"
The id_token contains three values of interest base64 encoded and separated by a dot '.':


After base64 decoding the first value will tell us which algorithm has been used to secure the ID token:
And the second value will contain the actual JWT token:
"sub": "bob",
"aud": "UUF9Fds67nnp6A",
"iat": 1449674327,
"exp": 1449734327,
"given_name": "Bob",
"email": "",
"family_name": "Windsor",
"name": "Bob Windsor",
"nonce": "1d5c428ffbff3eed95721339e67c56e8c2aa4add6bb493e436249578c81f88",
"iss": "",
"at_hash": "vosXxkYaqmZbbbMiUugXEA"
The third parameter will contain the digital signature (binary value) thus I cannot display it here.

After consuming the authorization code the user will be redirected back to the initially requested resource
HTTP/1.1 303 See Other

OpenID Connect with WS-Federation LoginNow after understanding the basic OpenID Connect flow lets extend this scenario by performing the login not directly at the OIDC service but instead using the Fediz-Plugin at the OIDC Service to redirect the user according to WS-Federation to the Fediz-IDP for user authentication. After successful login at the Fediz-IDP the user will be send back to the OIDC with a SAML token. This token can then be mapped to a JWT token for the OpenID connect login process.

(1) In the first step the user invokes the web portal.
(2) Since now existing session exists the user will be redirected to the OIDC Service according to OpenID Connect.
(3) An Apache Fediz Plugin is active on the OIDC Server. Since now previous session exists the Fediz Plugin will redirect the user to the RP-IDP according to WS-Federation.
(4) The user will see a login screen and will be redirected back to the OIDC server after successful authentication with a SAML token.
(5) The Fediz Plugin will store the SAML Token. OIDC will provide the requested code from step (2).
(6) The Web Portal can now exchange this code according to OAuth2 to get the JWT Token (transformation of the SAML token), as well as an access token to invoke another backend service.
(7) The REST Service will be invoked with the access token received in the previous step
Authorization: Bearer a8de6a544738c9e9036318ee78dfe7
(8) The REST Service will send the access token to the OIDC to ensure that this code is valid. (Unfortunately it is not defined within the standard how this validation should happen)

In my second part of this post, I'll explain how to setup a demonstrator for the above described use case.

Federated SSO with WS-Federation & OpenID ConnectAfter understanding OpenID Connect and WS-Federation Login I'll extend this scenario by one more degree of complexity thus providing us the flexibility which we discusses at the beginning to provide a SSO solution not just within one company but for multiple partners at the same time.

(1) A user from a partner company invokes the web portal.
(2) Since now existing session exists the user will be redirected to the OIDC Service according to OpenID Connect.
(3) An Apache Fediz Plugin is active on the OIDC Server. Since now previous session exists the Fediz Plugin will redirect the user to the RP-IDP according to WS-Federation.
(4) Since no existing session exists at the RP-IDP, the RP-IDP will perform a Home-Realm discovery and after that redirects the user to its own Requestor IDP (more details about this in the next section).
(5) After successful login the Requestor IDP will issue a SAML Token for the user and redirect the user back to the RP-IDP.
(6) The RP-IDP will to do a Claims or Identity Mapping and after that issue a new SAML token applicable for the OIDC Service and redirects the user back to the OIDC service.
(7) The Fediz Plugin at the OIDC service will store the SAML Token and OIDC will provide the requested code from step (2).
(8) The Web Portal can now exchange this code according to OAuth2 to get the JWT Token (transformation of the SAML token), as well as an access token to invoke a backend service.
(9) The REST Service will be invoked with the access token received in the step (8).
(10) The REST Service will send the access token to the OIDC to ensure that this code is valid. (Unfortunately it is not defined within the standard how this validation should happen)
Home Realm DiscoveryIf your web portal shall be used by users from multiple realms (e.g. partner networks), you need to find a way to discover the home realm of each user. The OpenID Connect Standard provides a parameter login_hint for this purpose whereas WS-Federation Standard offers a whr parameter for this purpose.

There are several ways to do a home realm discovery:
  1. Dedicated URLs
    You can provide different URLs for each user group. This can be done by adding the login_hint parameter directly to the URL which the user is invoking (e.g. link within a different portal which the user usually access first). Also very famous is the usage of different domain names with a reverse proxy in place which adds the login_hint / whr parameter.
  2. E-Mail Address
    If there is just a single page which will be used by all user groups it is also a good choice to ask the user for his/her E-Mail address and then use this as the  the login_hint.The OIDC service could use the domain name of this E-Mail Address to set it as the whr parameter for home realm discovery at the RP-IDP. The RP-IDP would need a mapping table of domain names and Requestor IDP URLs to send the user to its home IDP.
    One disadvantage of this solution is that the user will most likely be required to enter his/her E-Mail address twice. First at the portal to initiate the home realm discovery and later for the login at the Requestor IDP. This is because WS-Federation does not provide a felxible login_hint but instead only a more static whr parameter which will be the same value for all users within one group. You can improve the user experience if you use cookies to remember the selected home realm of a user until a user initiated logout takes place.
  3. IP Range
    IP ranges can also be used for home realm discovery but are usually not a good choice because users will not just login from a company network with a static IP but also from mobile devices with a dynamic IP range.
  4. Miscellaneous
    Any other way to securely identify the home realm of a user would also be acceptable, but will usually require custom development efforts to the services.
Categories: Jan Bernhardt

Javascript Object Signing and Encryption (JOSE) support in Apache CXF - part III

Colm O hEigeartaigh - Mon, 12/07/2015 - 18:03
This is the third article in a series of posts on support for Javascript Object Signing and Encryption (JOSE) in Apache CXF. The previous article described how to encrypt content using the JSON Web Encryption specification. This post covers support for JSON Web Tokens (JWT) in Apache CXF. The JWT spec is not strictly part of the JOSE specification set, but it makes sense to cover it in this series of posts, as it is a natural extension of the JOSE specs to convey claims.

1) Test Cases:

As before, let's start by looking at some practical unit tests on github:
  • cxf-jaxrs-jose: This project contains a number of tests that show how to use the JSON Security functionality in Apache CXF to sign and encrypt JSON payloads to/from a JAX-RS service.
These tests mostly follow the same basic format. The web service configuration defines a number of endpoints that map to the same web service implementation (a simple DoubleItService, which allows a user to POST a number and receive the doubled amount, where both the request and response are encoded via JSON). The client test code first constructs a JWT Token and then includes it in the message payload by adding a specific provider. The JWT Token is then processed by a provider on the receiving side. We will cover the individual tests in more detail below.

2) Constructing JWT Tokens

Apache CXF provides an easy to use API to create JWT Tokens. Let's look at how this is done in one of the tests - the JWTAuthenticationTest. The tests construct a JwtClaims Object, which has convenient set/get methods for the standard JWT Claims. For example:

The JwtClaims Object can be passed through to the constructor of a JwtToken Object. To serialize the JwtToken in the request simply add the JwtAuthenticationClientFilter to the client provider list, and specify the JwtToken Object as a message property under "jwt.token". Alternatively, the JwtClaims Object can be passed without having to construct a JwtToken via the property "". On the receiving side, a JWTToken can be processed by the JwtAuthenticationFilter provider.

3) Authentication and Authorization using signed JWT Tokens

By default, the JwtAuthenticationClientFilter signs the JWT Token. The signature configuration is the exact same as that used for JWS as covered in the first article. On the receiving side, the JwtAuthenticationFilter will set up a security context for the authenticated client, assuming that a public key signature algorithm was used to sign the token. The "sub" (Subject) claim from the token gets mapped to the principal of the security context.

As the JWT Token can convey arbitrary claims, it can be used for RBAC authorization. This is demonstrated in the JWTAuthorizationTest. A role called "boss" is inserted into the token. On the receiving side, the JwtAuthenticationFilter is configured to use the "role" claim in the token to extract roles for the authenticated principal and to populate the security context with them. As part of the test-case, CXF's SimpleAuthorizingInterceptor is used to require that a client must have a role of "boss" to invoke on the web service method in question.

4) Encrypting JWT Tokens

It is very easy to encrypt JWT Tokens (as well as both sign and encrypt) them in CXF. The JwtAuthenticationClientFilter needs to be configured to also encrypt the token, and the same configuration is used as for JWE in the previous article. Similarly, on the receiving side the JwtAuthenticationFilter must have the property "jweRequired" set to "true" to decrypt incoming encrypted tokens. See the JWTEncryptedTest test for some examples. 

5) Token validation

On receiving a JAX-RS request containing a JWT token, the
JwtAuthenticationFilter will first parse the token, and then verify the signature (if present) and decrypt the token (if encrypted). It then performs some quality of service validation on the token claims, which I'll detail here. This validation can be easily modified by overriding the protected "validateToken" method in JwtAuthenticationFilter.
  • The "exp" (Expiration Time) claim is validated if present. If the expiry value is before the current date/time, then the token is rejected. 
  • The "nbf" (Not Before) claim is validated if present. If the not before value is after the current date/time, then the token is rejected. 
  • The "iat" (Issued At) claim is validated if present. To validate the "iat" claim, a "ttl" property must be set on the JwtAuthenticationFilter.
  • Either an "iat" or "exp" claim must be present in the token, as otherwise we have no way of enforcing an expiry on a token.
  • A clockskew value can also be configured on the JwtAuthenticationFilter via the "clockOffset" property.
  • The "aud" (Audience) claim is validated. This claim must contain at least one audience value which matches the endpoint address of the recipient.
Categories: Colm O hEigeartaigh

Javascript Object Signing and Encryption (JOSE) support in Apache CXF - part II

Colm O hEigeartaigh - Wed, 12/02/2015 - 18:49
This is the second in a series of blog posts on the support for the Javascript Object Signing and Encryption (JOSE) specifications in Apache CXF. The first article covered how to sign content using the JSON Web Signature (JWS) specification. In this post we will look at how to encrypt content using the JSON Web Encryption (JWE) specification.

1) Test Cases:

As before, let's start by looking at some practical unit tests on github:
  • cxf-jaxrs-jose: This project contains a number of tests that show how to use the JSON Security functionality in Apache CXF to sign and encrypt JSON payloads to/from a JAX-RS service.
For now let's look at the tests contained in JWETest. These tests mostly follow the same basic format. The web service configuration defines a number of endpoints that map to the same web service implementation (a simple DoubleItService, which allows a user to POST a number and receive the doubled amount, where both the request and response are encoded via JSON). The client test code uses the CXF WebClient API to encrypt the message payload by adding a specific provider. The message in turn is decrypted by a provider on the receiving side. You can run the test via the command line "mvn test -Dtest=JWETest", and the message requests and responses will appear in the console.

2) Compact vs. JSON Serialization

Just like the JWS specification, there are two different ways of serializing JWE structures. Compact serialization is a URL-safe representation that is convenient to use when you only have a single encrypting entity. JSON serialization respresents the JWE structures as JSON objects. As of the time of publishing this post, CXF only has interceptors for the compact approach. However I'm told the JSON serialization case will be supported very soon :-)

The providers to use for the compact case on both the client + receiving sides are:
  • Compact: JweWriterInterceptor (out) + JweContainerRequestFilter (in)
3) Security Configuration

As well as adding the desired providers, it is also necessary to specify the security configuration to set the appropriate algorithms, keys, etc. to use. The CXF wiki has an extensive list of all of the different security configuration properties. For encryption, we need to first load the encrypting key (either a JKS keystore or else a JSON Web Key (JWK) is supported).

As well as defining the encryption key, we also need to configure the algorithms to encrypt the content as well as to encrypt the key. The list of acceptable encryption algorithms for JWE is defined by the JSON Web Algorithms (JWA) spec. For content encryption, the supported algorithms are all based on AES (CBC/GCM mode) with different key sizes. For key encryption, various schemes based on RSA, AES KeyWrap/GCM, Elliptic Curve Diffie-Hellman, PBES2 are supported, as well as a symmetric encryption option.

For example, the tests use the following configuration to load a public key from a Java KeyStore, and to use the RSA-OAEP key encryption algorithm, as well as a 128-bit AES content encryption algorithm in CBC mode, using HMAC-SHA256 to generate the authentication code:
The service side configuration is largely the same, apart from the fact that we need to specify the "" configuration tag to load the private key. The encryption algorithms must also be specified to impose a constraint on the desired algorithms.

4) Encrypting XML payload

Similar to the signature case, it is possible to use JWE to encrypt an XML message, and not just a JSON message. An example is included in JWETest ("testEncryptingXMLPayload").  The configuration is exactly the same as for the JSON case. 

5) Including the encrypting key

It is possible to include the encrypting certificate/key in the JWE header by setting one of the following properties:
  • - Include the JWK public key for encryption in the "jwk" header.
  • - Include the X.509 certificate for encryption in the "x5c" header.
  • - Include the JWK key id for encryption in the "kid" header.
  • - Include the X.509 certificate SHA-1 digest for encryption in the "x5t" header.
It could be useful to include the encrypting certificate/key if the recipient has multiple decryption keys and doesn't know which one to use to decrypt the request.

6) Signing + encrypting a message

It is possible to both sign and encrypt a message by combining the JWS + JWE interceptors. For example, simply adding the JweWriterInterceptor and JwsWriterInterceptor providers on the client side will both sign and encrypt the request. An example is included in the github project above (JWEJWSTest). 
Categories: Colm O hEigeartaigh

Javascript Object Signing and Encryption (JOSE) support in Apache CXF - part I

Colm O hEigeartaigh - Mon, 11/30/2015 - 18:39
The Javascript Object Signing and Encryption (JOSE) specifications cover how to sign and encrypt data using JSON. Apache CXF has excellent support for all of the JOSE specifications (see the documentation here), thanks largely to the work done by my colleague Sergey Beryozkin. This is the first in a series of blog posts describing how to use and implement JOSE for your web services using Apache CXF. In this post, we will cover how to sign content using the JSON Web Signature (JWS) specification.

1) Test Cases:

Let's start by looking at some practical unit tests on github:
  • cxf-jaxrs-jose: This project contains a number of tests that show how to use the JSON Security functionality in Apache CXF to sign and encrypt JSON payloads to/from a JAX-RS service.
For now let's look at the JWSSignatureTest. These tests mostly follow the same basic format. The web service configuration defines a number of endpoints that map to the same web service implementation (a simple DoubleItService, which allows a user to POST a number and receive the doubled amount, where both the request and response are encoded via JSON). The client test code uses the CXF WebClient API to sign the message payload by adding a specific provider. The message in turn is validated by a provider on the receiving side. You can run the test via the command line "mvn test -Dtest=JWSSignatureTest", and the message requests and responses will appear in the console.

For example, here is the output of the "testSignatureCompact" request. The Payload consists of the concatenated (+ separated by a '.') BASE-64 URL encoded JWS header (e.g. containing the signature algorithm, amongst other values), the BASE-64 URL encoded message payload, and the BASE-64 URL encoded signature value.

2) Compact vs. JSON Serialization

The JWS specification defines two different ways of serializing the signatures. Compact serialization is a URL-safe representation that is convenient to use when you only have a single signing entity. JSON serialization resprents the JWS structures as JSON objects, and allows multiple signatures to be included in the request as a result. The JWSSignatureTest includes both examples ("testSignatureListProperties" and "testSignatureCompact"). It's very easy to experiment with both approaches, as you only have to use different providers on both the client + receiving sides:
  • JSON Serialization: JwsJsonWriterInterceptor (out) + JwsJsonContainerRequestFilter (in)
  • Compact: JwsWriterInterceptor (out) + JwsContainerRequestFilter (in)
3) Security Configuration

As well as adding the desired providers, it is also necessary to specify the security configuration to set the appropriate algorithms, keys, etc. to use. The CXF wiki has an extensive list of all of the different security configuration properties. For signature, we need to first load the signing key (either a JKS keystore or else a JSON Web Key (JWK) is supported).

As well as defining a signing key, we also need to configure the signing algorithm. The list of acceptable signing algorithms for JWS is defined by the JSON Web Algorithms (JWA) spec. For signature, this boils down to a public key signature scheme based on either RSA or EC-DSA, or a symmetric scheme using HMAC.

For example, the tests use the following configuration to load a private key from a Java KeyStore, and to use the signature scheme of RSASSA-PKCS1-v1_5 using SHA-256:
The service side configuration is largely the same, apart from the fact that we don't need to specify the "" configuration tag, as we don't need to load the private key. The signature algorithm must be specified to impose a constraint on the acceptable signature algorithm.

4) Signing XML payload

The JWS payload (the content to be signed) can be any binary content and not just a JSON Object. This means that we can use JWS to sign an XML message. This is a really cool feature of the specification in my opinion, as it essentially removes the need to use XML Signature to sign XML payload. An example of this is included in the JWSSignatureTest. The configuration is exactly the same as for the JSON case.

5) Including the signing key

It is possible to include the signing certificate/key in the JWS header by setting one of the following properties:
  • -  Include the JWK public key for signature in the "jwk" header.
  • - Include the X.509 certificate for signature in the "x5c" header.
  • - Include the JWK key id for signature in the "kid" header.
  • Include the X.509 certificate SHA-1 digest for signature in the "x5t" header.
One advantage of including the entire certificate is that the service doesn't need to store the client certificate locally, but only the issuing certificate.
Categories: Colm O hEigeartaigh

Enterprise ready request logging with CXF 3.1.0 and elastic search

Christian Schneider - Mon, 11/30/2015 - 15:24

Blog post edited by Christian Schneider

You may already know the old CXF LoggingFeature (org.apache.cxf.feature.LoggingFeature). You added it to a JAXWS endpoint to enable logging for a CXF endpoint at compile time.

While this already helped a lot it was not really enterprise ready. The logging could not be controlled much at runtime and contained too few details. This all changes with the new CXF logging support and the up coming Karaf Decanter.

Logging feature in CXF 3.1.0

In CXF 3.1 this code was moved into a separate module and gathered some new features.

  • Auto logging for existing CXF endpoints
  • Uses slf4j MDC to log meta data separately
  • Adds meta data for Rest calls
  • Adds MD5 message id and exchange id for correlation
  • Simple interface for writing your own appenders
  • Karaf decanter support to log into elastic search
Manual UsageCXF LoggingFeature <jaxws:endpoint ...> <jaxws:features> <bean class="org.apache.cxf.ext.logging.LoggingFeature"/> </jaxws:features> </jaxws:endpoint> Auto logging for existing CXF endpoints in Apache Karaf

Simply install and enable the new logging feature:

Logging feature in karaf feature:repo-add cxf 3.1.0 feature:install cxf-features-logging config:property-set -p org.apache.cxf.features.logging enabled true

Then install CXF endpoints like always. For example install the PersonService from the Karaf Tutorial Part 4 - CXF Services in OSGi. The client and endpoint in the example are not equipped with the LoggingFeature. Still the new logging feature will enhance the clients and endpoints and log all SOAP and Rest calls using slf4j. So the logging data will be processed by pax logging and by default end up in your karaf log.

A log entry looks like this:

Sample Log entry 2015-06-08 16:35:54,068 | INFO | qtp1189348109-73 | REQ_IN | 90 - org.apache.cxf.cxf-rt-features-logging - 3.1.0 | <soap:Envelope xmlns:soap=""><soap:Body><ns2:addPerson xmlns:ns2="" xmlns:ns3=""><arg0><id>3</id><name>Test2</name><url></url></arg0></ns2:addPerson></soap:Body></soap:Envelope>

This does not look very informative. You only see that it is an incoming request (REQ_IN) and the SOAP message in the log message. The logging feature provides a lot more information though. You just need to configure the pax logging config to show it.

Slf4j MDC values for meta data

This is the raw logging information you get for a SOAP call:

FieldValue@timestamp2015-06-08T14:43:27,097ZMDC.addresshttp://localhost:8181/cxf/personServiceMDC.bundle.id90MDC.bundle.nameorg.apache.cxf.cxf-rt-features-loggingMDC.bundle.version3.1.0MDC.content-typetext/xml; charset=UTF-8MDC.encodingUTF-8MDC.exchangeId56b037e3-d254-4fe5-8723-f442835fa128MDC.headers{content-type=text/xml; charset=UTF-8, connection=keep-alive, Host=localhost:8181, Content-Length=251, SOAPAction="", User-Agent=Apache CXF 3.1.0, Accept=*/*, Pragma=no-cache, Cache-Control=no-cache}MDC.httpMethodPOSTMDC.messageIda46eebd2-60af-4975-ba42-8b8205ac884cMDC.portNamePersonServiceImplPortMDC.portTypeNamePers<soap:Envelope xmlns:soap=""><soap:Body><ns2:getAll xmlns:ns2=""; xmlns:ns3=""/></soap:Body></soap:Envelope>;threadNameqtp80604361-78timeStamp1433774607097

Some things to note:

  • The logger name is <service namespace>.<ServiceName>.<type> karaf by default only cuts it to just the type.
  • A lot of the details are in the MDC values

You need to change your pax logging config to make these visible.

You can use the logger name to fine tune which services you want to log this way. For example set the debug level to WARN for noisy services to avoid that they are logged or log some services to another file.

Message id and exhange id

The messageId allows to uniquely identify messages even if you collect them from several servers. It is also transported over the wire so you can correlate a request sent on one machine with the request received on another machine.

The exchangeId will be the same for an incoming request and the response sent out or on the other side for an outgoing request and the response for it. This allows to correlate request and responses and so follow the conversations.

Simple interface to write your own appenders

Write your own LogSender and set it on the LoggingFeature to do custom logging. You have access to all meta data from the class LogEvent.

So for example you could write your logs to one file per message or to JMS.

Karaf decanter support to write into elastic search

Many people use elastic search for their logging. Fortunately you do not have to write a special LogSender for this purpose. The standard CXF logging feature will already work.

It works like this:

  • CXF sends the messages as slf4j events which are processed by pax logging
  • Karaf Decanter LogCollector attaches to pax logging and sends all log events into the karaf message bus (EventAdmin topics)
  • Karaf Decanter ElasticSearchAppender sends the log events to a configurable elastic search instance

As Decanter also provides features for a local elastic search and kibana instance you are ready to go in just minutes.

Installing Decanter for CXF Logging feature:repo-add mvn:org.apache.karaf.decanter/apache-karaf-decanter/3.0.0-SNAPSHOT/xml/features feature:install decanter-collector-log decanter-appender-elasticsearch elasticsearch kibana

After that open a browser at http://localhost:8181/kibana. When decanter is released kibana will be fully set up. At the moment you have to add the logstash dashboard and change the index name to [karaf-]YYYY.MM.DD.

Then you should see your cxf messages like this:

Kibana easily allows to filter for specific services and correlate requests and responses.

This is just a preview of decanter. I will do a more detailed post when the first release is out.


View Online
Categories: Christian Schneider

WADL and Swagger United in Apache CXF

Sergey Beryozkin - Fri, 11/20/2015 - 18:33
Who could've thought that Swagger and WADL can be real friends ?
Both Swagger and WADL are about describing REST APIs and while the former has a definite momentum, the latter has proved to be very capable and helpful to JAX-RS users.

The important thing is that we have users who submit WADL documents  to the runtime or build time code generators which is all working fine. We also have Swagger users who use cool Swagger features and being happy with a nice UI being generated. And WADL users, while being happy with WADL (which IMHO is indeed a very capable language for describing schema rich XML but with some extensions - even JSON - services) would like to use Swagger to introspect the code generated by WADL processors and have a nice API UI.

So my colleague Andrei and  Francesco, Apache Syncope maestro, have driven the work about enhancing a WADL generator to set WADL documentation fragments as Java Docs in the generated sources and then having CXF Swagger features being very smart about enhancing Swagger JSON payloads with these Java Docs, with Francesco doing some magic there. I should also mention Andriy Redko doing some work earlier on directly with Swagger for it to better support JAX-RS annotations and initiating the CXF Swagger project and Aki Yoshida doing a lot of Swagger2 work next.

So here you go, WADL and Swagger United in Apache CXF.

IMHO this project has been a perfect example of the power of the Open Source collaboration with the contributors from different teams working effectively on this project.

Categories: Sergey Beryozkin

HTrace your Apache CXF Service flows

Sergey Beryozkin - Fri, 11/20/2015 - 18:10
Andriy Redko keeps pushing CXF to the next level with adding new features nearly every few weeks :-).

One of his latest projects has been to do with wiring Apache HTrace into CXF such that CXF users can HTrace calls starting from CXF clients going to CXF servers and then to such HTrace aware containers as HBase  and using the collectors like Zipkin.

I'm looking forward to Andriy talking in detail about it on his blog and at the conferences, but in meantime you can check the documentation. Note that it works not only for JAX-RS but for JAX-WS too: if we can have a new feature working with both frontends then you know it will be done. The demo is here.

Give it a try and stay on top of the web services game :-)
Enjoy !

Categories: Sergey Beryozkin

JAX-RS 2.1 specification work has started

Sergey Beryozkin - Fri, 11/20/2015 - 17:51
JAX-RS 2.1 specification work has finally started after a rather quiet year and this is a good news for JAX-RS users at large and CXF JAX-RS users in particular.
JAX-RS 2.1 is entirely Java 8 based and a number of new enhancements are on the way. I was concerned earlier on that having a Java 8 will slow down the adoption but I think now the spec leads were right, Java 8 is so rich and JAX-RS needs to be open to accepting the latest Java features - ultimately this is what will excite the users.

The main new features list is: support for Server-Sent Events (something CXF users will enjoy experimenting with while also keeping in mind CXF has some great WebSocket support done by Aki), enhanced NIO support and introducing a reactive mode into Client API.

I've already mentioned before that JAX-RS 2.0 AsyncResponse API is IMHO very impressive as it makes a fairly complex task of dealing with suspended invocations becoming rather trivial to deal with. Marek and Santiago are doing it again with the new 2.1 proposals. Of course there will be some minor disagreements here and there but overall I'm very positive about this new JAX-RS project.

We now have a CXF Java 8 master branch to support the future JAX-RS 2.1 features but having a Java 8 trunk is great for all of the CXF community.

What is really good is that there appears to be no obvious end to the new requirements coming into the JAX-RS space. The HTTP services space is wide open, with the new ideas generated around the security, faster processing, etc, and it all will be eventually available as future JAX-RS features. I'm confident JAX-RS 3.0 will be coming in due time too.

Categories: Sergey Beryozkin

New security advisory for Apache CXF

Colm O hEigeartaigh - Mon, 11/16/2015 - 13:28
A new security advisory has been released for Apache CXF, which is fixed in the 3.1.3, 3.0.7 and 2.7.18 releases.
  • CVE-2015-5253: Apache CXF SAML SSO processing is vulnerable to a wrapping attack
Apache CXF supports the SAML SSO protocol with JAX-RS web service endpoints. It is possible for a malicious user to construct a SAML Response (the response from the SAML SSO IdP to the endpoint) via a so-called "wrapping attack", to allow that user to log in instead of the authenticated user associated with the signed SAML Assertion.

Please see the Apache CXF security advisories page for more information.
Categories: Colm O hEigeartaigh

Testing Kerberos with Web Services using Apache Kerby

Colm O hEigeartaigh - Wed, 11/11/2015 - 13:13
The previous blog post described how to use Apache Directory to easily create a KDC via Java annotations for kerberos integration testing. In this post, we will look at an alternative way of setting up a KDC for integration testing using Apache Kerby.

Apache Kerby is a new subproject of Apache Directory that aims to provide a complete Kerberos solution in Java. Version 1.0.0-RC1 has recently been released and is available for testing. Apache Kerby consists of both a KDC as well as a client API, that is completely independent of the GSS API that comes with Java. A key selling point of Apache Kerby is that it is very easy and fast to setup and deploy a KDC. It is possible to set up a KDC completely in code, without having to edit any configuration files or configure any system properties.

Let's see how this is done by looking at a project I created on github:
  • cxf-kerberos-kerby: This project contains a number of tests that show how to use Kerberos with Apache CXF, where the KDC used in the tests is based on Apache Kerby.
The KDC is launched in the test-code, and is pretty much as straightfoward as the following code snippet:

The first block of code configures the host, realm, transports and ports, while the second creates the client, service and TGT principals that are used in the tests. No configuration files required! As well as showing how to use Apache CXF to authenticate using both Kerberos and Spnego for a JAX-WS service, the AuthenticationTest also includes unit tests for getting a service ticket from the Kerby KDC using the Java GSS API as well as the Kerby client API. Using the Kerby client API is as simple as this:

Have fun playing around with Apache Kerby and please join and contribute to the project if you are interested!
Categories: Colm O hEigeartaigh

Testing Kerberos with Web Services using Apache Directory

Colm O hEigeartaigh - Mon, 10/26/2015 - 12:59
Apache CXF supports Kerberos for web services both via the Kerberos Token Profile of WS-Security, where the kerberos ticket is conveyed as a BinarySecurityToken in the security header of the client request, and over HTTP via the Negotiate authentication scheme. If you are developing kerberos-enabled web services using a framework like Apache CXF, a natural question to ask is how to set up a Kerberos KDC to test your web services prior to deployment. This is the first of two blog posts that shows two different ways to easily set up a KDC using open source projects for kerberos integration testing.

At ApacheCon EU 2014 in Budapest, I attended a great talk by Emmanuel Lécharny entitled "Testing LDAP Implementations". The talk covered how the Apache Directory project can be used to easily deploy Kerberos and LDAP servers in your test-code via annotations. This was music to my ears, as I had written a bunch of tests in Apache CXF for both LDAP and kerberos that were not run as part of the normal build, as they required a local KDC to run successfully. After this talk I got involved in the Apache Directory project, and converted the tests in Apache CXF to use Apache Directory instead, so they could be run as part of the normal build cycle. I also made some small improvements which I'll describe as part of this post.

I've created a project in github that shows how to use Apache Directory to set up a KDC, and how to use Apache CXF to authenticate to a web service using Kerberos, for both JAX-RS and JAX-WS:
  • cxf-kerberos: This project contains a number of tests that show how to use Kerberos with Apache CXF.
Both test-cases use an annotation to load a kerberos.ldif file, containing the information required to set up Kerberos principals in the KDC for testing:

 Another annotation sets up the Directory Service:

Finally, an annotation adds a KDC server:

The "KRB" protocol was added as part of DIRSERVER-2031 in the 2.0.0-M20 release. Previously, you could specify either "TCP" or "UDP" for the protocol attribute when testing Kerberos. However, this meant that they could not share the same port. The "KRB" protocol generates both TCP and UDP transports on the port provided, or otherwise on a random port. Previously, the random port generation was not working, as it always defaulted to 1024. Random port generation is an essential feature for testing as part of a build cycle, as hard-coded ports tend to cause problems on continuous integration platforms. Using a random port also means that the krb5.conf file used by the CXF clients must be read in, and the random port substituted into the file before writing it out again, as otherwise the clients would have no way of knowing the port the KDC was running on.
Categories: Colm O hEigeartaigh

A certificate revocation security vulnerability in Java

Colm O hEigeartaigh - Fri, 10/23/2015 - 12:04
A few days ago, Oracle released a Critical Patch Update containing fixes for various security vulnerabilities. In particular, the update contained fixes for 25 security vulnerabilities in Java itself. One of them, CVE-2015-4868, was discovered by me and duly disclosed to Oracle earlier this year. This issue has now been fixed in this Critical Patch Update (and included in Java 1.8.0_65), and so I am free to describe it.

1) Background

I first noticed this issue in the context of signature validation of SOAP web service requests. A signed SOAP request involves using XML Signature to sign some part of the request, where the resulting Signature structure is inserted into the security header of the request. The Signature contains a KeyInfo Element, which references the (public) key to use to validate the request. The recipient must resolve the appropriate public key, establish trust in it, and use it to validate the signature.

A common use-case is when the certificate used to validate the signature is included directly in the request, by BASE-64 encoding it in the security header. Optionally, the full certificate chain can be included instead. The recipient must take the certificates and establish a trust chain using a CA certificate stored in a local truststore, which is then validated.

However, what if the signing certificate has been revoked by the issuing CA? In this case, we can specify a Certificate Revocation List, and include it as part of the validation of the trust chain.

2) The vulnerability

Now to the vulnerability. Under the more usual use-case of just including the signing certificate in the security header, and establishing a trust-chain using a local truststore and CRL file, everything was working fine. Namely, if the signing certificate was trusted, but revoked, then the CertPath validation failed. However, if the issuing certificate of the signing certificate was also included in the security header, then CRL validation was not failing! This vulnerability exists in a range of JDK 8 versions prior to 1.8.0_65. It does not exist prior to JDK 8.

To see how this works using the Java CertPathValidator API, I created a simple maven-based unit test in github:
  • java.crls - A testcase that show how to include a CRL when validating the certificate path of a certificate.
The test has a JUnit failure assertion that asserts that the CertPathValidator validation should fail (as the signing certificate has been revoked). However, this failure assertion is not met when run locally with Java 1.8.0_51. With a Java version post-1.8.0_65 the failure assertion is met, and the test passes.
Categories: Colm O hEigeartaigh

[OT] Apache CXF: Nothing Else Matters !

Sergey Beryozkin - Fri, 10/09/2015 - 18:40
One can ask, do web services still matter in the today's world of emerging technologies such as Cloud and Big Data ?

Of course they do still matter. Take Big Data. The important thing to realize is as far as a remote client interacting with your HTTP server which internally initiates BigData flows is concerned it is still a client and HTTP server only - the client submits the data and gets the response it needs - the mechanism used to produce this response is, and has to be, completely opaque to the remote client, nothing unusual here, simply a proper service design leaking no implementation details to the client. In some cases one may not want to link BigData response streams to remote clients but in other cases it may make a perfect sense.

So yes, the web services do still matter because one still needs a production-quality, secure, flexible HTTP layer between the remote clients and internal data systems.

In fact, if you are an Apache CXF user, I can already hear you all saying (or even singing ?), Apache CXF: Nothing Else Matters ! Just make it loud enough to have your colleagues from the other team hear it :-)
Categories: Sergey Beryozkin

SurfCoastCentury 100km the video

Olivier Lamy - Fri, 10/09/2015 - 02:36
So I finally found a bit of time to make a movie (please be indulgent I'm not a professional :-) )

If you have read the run report, here the video:

Yes I enjoyed a LOT :-)

I hope after watching this, you will want to come here down under for a little run :-)
Categories: Olivier Lamy

Make your CXF JAX-RS servers OpenId Connect ready

Sergey Beryozkin - Thu, 10/08/2015 - 23:04
We've been doing a lot of work during the last year to ensure CXF developers can start experimenting fast and effectively with the latest RS security advancements such as OAuth2 and JOSE which are also the building blocks for OpenId Connect (OIDC).

With OAuth2 and JOSE modules becoming quite solid, it was time to turn the attention to OIDC, OIDC RP being a starting point - which is a mechanism to log on the users into the servers by federating to OIDC IDP providers such as Google and Facebook.  OIDC is a fairly complex protocol but with OAuth2 and JOSE covered it was not that tricky after all.

The initial result is these two demos:

1. BigQuery

This demo shows a client OAuth2 server that accesses a user's BigQuery data-sets. The demo checks a public data-set of Shakespeare works but once you have a Google Developer account you can easily create your own BigQuery data-set and use the demo to access it instead.

2. Basic OIDC

This demo shows that a server does not have to be specifically coded around OAuth2 flows to use OIDC - it only uses OIDC to log-in the users and then work with these users.

I'd like to encourage you to run these demos - ask at CXF users or #apache-cxf if you have any issues running them and start making your CXF servers OIDC-aware now !

I look forward to the feedback from the early adopters. And please watch this space - this is only a start :-)

Categories: Sergey Beryozkin


Subscribe to Talend Community Coders aggregator