Wednesday, June 10, 2015

Apache CXF Fediz 1.2.0 tutorial - part I

The previous blog entry gave an overview of the new features in Apache CXF Fediz 1.2.0. This post first focuses on setting up and running the IdP (Identity Provider) and the sample simpleWebapp in Apache Tomcat.

1) Deploying the 1.2.0 Fediz IdP in Apache Tomcat

Download Fediz 1.2.0 and extract it to a new directory (${fediz.home}). We will use a Apache Tomcat 7 container to host the Idp. To deploy the IdP 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
  • Download and copy the hsqldb jar (e.g. hsqldb- to ${catalina.home}/lib
Now we need to set up TLS:
  • The keys that ship with Fediz 1.2.0 are 1024 bit DSA keys, which will not work with most modern browsers (this will be fixed for 1.2.1). 
  • So with 1.2.0 we need to download the keys from git, rather than use the keys in the distribution
  • Download idp-ssl-key.jks and idp-ssl-trust.jks from here.
  • Copy idp-ssl-key.jks and idp-ssl-trust.jks to ${catalina.home}.
  • Copy both jks files as well to ${catalina.home}/webapps/fediz-idp/WEB-INF/classes/ (after Tomcat is started)
  • Edit the TLS Connector in ${catalina.home}/conf/server.xml', e.g.: <Connector port="8443" 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:8443/fediz-idp-sts/REALMA/STSServiceTransport?wsdl'

For a more thorough test, enter the following in a web browser - you should be directed to the URL for the service application (404, as we have not yet configured it):


2) Deploying the simpleWebapp in Apache Tomcat

To deploy the service to Tomcat:
  • Copy ${fediz.home}/examples/samplekeys/rp-ssl-server.jks (rp-ssl-key.jks from Fediz 1.2.1) 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.
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.


  1. Hi Colm,
    I have setup two different apache tomcat server one for IDP/STS and another for my RP and this is working fine for sampleWebapp example. Now I am integrating RP in my another webapp and trying to connect with IDP but I am getting Exception. Saying request is not validated. I understand the problem that this is configuration issue. I need your help for register my RP to Fediz IDP. I followed and I m using https://localhost:9443/fediz-idp/services/rs?_wadl wadl using SOAPUI to change the contaxt path in IDP configuration but also facing authentication issue here. I have following queries related to my issue.
    1. How can I register my own RP(Relying party) in fediz IDP and STS.
    2. During the build of STS src I am getting some Ldap configuration exception. I am following README.txt
    Hope to hear from you soon :) -Raj

  2. Hi,

    Please send an email to the CXF users list with this information + I will take a look.


    1. Hi Colm,
      Thanks, I have send an email to the CXF users list. I am facing problem during applying security in SOAPUI for https://localhost:9443/fediz-idp/services/rs?_wadl. I get some exception in IDP server console when I do POST https://localhost:9443/fediz-idp/services/rs/applications to register this application via the IDP REST Interface.

      2015-08-19 11:19:39,964 [http-bio-9443-exec-1] WARN org.apache.cxf.jaxrs.utils.JAXRSUtils - No operation matching request path "/fediz-idp/services/rs" is found, Relative Path: /
      , HTTP Method: POST, ContentType: application/xml, Accept: */*,. Please enable FINE/TRACE log level for more details.
      2015-08-19 11:19:39,964 [http-bio-9443-exec-1] WARN - Exception occured processing REST request: HTTP 405 Method
      Not Allowed HTTP 405 Method Not Allowed
      at org.apache.cxf.jaxrs.utils.SpecExceptions.toHttpException(
      at org.apache.cxf.jaxrs.utils.ExceptionUtils.toHttpException(

    2. Thank you Colm,
      I got solution on CXF user lists from Jan Bernhardt. And now it's working fine. Thank you @Jan :)

  3. I am configuring the sample app, however the idp is redirecting to https://localhost:12443/fediz-idp-remote/federation?wa=wsignin1.0&wtrealm=urn%3Aorg%3Aapache%3Acxf%3Afediz%3Aidp%3Arealm-A&wreply=https%3A%2F%2Flocalhost%3A9443%2Ffediz-idp%2Ffederation&whr=urn:org:apache:cxf:fediz:idp:realm-B&wctx=4327ff71-df9e-4428-9fdd-9138e6330413
    instead of 8443 port in IDP.

  4. When the browser is redirected to the IdP are you selecting "Realm B" in the drop down list? This will redirect to "12443"...instead you should be selecting "Realm A".

  5. Thanks for the reply, If there is an existing REST calls which are just having basic authentication but i dont want another call, how this can be achieved in fediz...

  6. I don't understand the question. I suggest adding more detail and asking it on the CXF users mailing list.

  7. Hi Colm,
    I tried to execute simplewebApp ( HelloWorld) with version 1.4.3 . I have configured all the steps mentioned in your website and have validate the urls to check if the services are working as expected.

    when I invoke https://localhost:8443/fedizhelloworld/secure/fedservlet , I am promoted for userid and pwd, which gets authenticated and I can see token successfully getting created in the IDP . Logs provided below. However, post authentication, I get redirected to https://localhost:8443/fedizhelloworld/secure/fedservlet and see 401 error . I do not see any errors in the RP tomcat. I tried to check all the configurations, but they look good.

    Logs of IDP -
    INFO org.apache.cxf.fediz.service.idp.service.jpa.ConfigServiceJPA - Old Spring security context restored
    INFO org.apache.cxf.fediz.service.idp.FedizEntryPoint - Redirect to https://localhost:9443/fediz-idp/federation/up?wa=wsignin1.0&wreply=https%3A%2F%2Flocalhost%3A8443%2Ffedizhelloworld%2Fsecure%2Ffedservlet&wtrealm=urn%3Aorg%3Aapache%3Acxf%3Afediz%3Af
    INFO - Enriched AuthenticationToken added
    INFO org.apache.cxf.fediz.service.idp.beans.CacheSecurityToken - Token [IDP_TOKEN=_acb475a2-79b6-419f-91b5-4d3276b014d0] for realm [urn:org:apache:cxf:fediz:idp:realm-A] successfully cached.
    INFO org.apache.cxf.fediz.service.sts.realms.SamlRealmCodec - Realm parsed in certificate: REALMA
    INFO org.apache.cxf.fediz.service.idp.beans.STSClientAction - [RP_TOKEN=_c8f45aad-0027-4c3b-b7e8-8788503d8c06] successfully created for realm [urn:org:apache:cxf:fediz:fedizhelloworld] on behalf of [IDP_TOKEN=_acb475a2-79b6-419f-91b5-4d3276b014d0]

  8. I'm wondering why the log says it's redirecting to "9443"? In any case it appears to be issuing the token correctly. Try turning up logging to DEBUG and see if anything pops out.

  9. I could not find any errors with DEBUG mode as well. IDP instance is being executed from 9443 port, hence redirecting to that port. I tried to get SAML response - and not sure if the following is leading to the issue .

    And my browser shows 8:30 AM UTC-5.

  10. Post authentication, SAML communication recorded
    Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
    Accept-Language: en-US,en;q=0.5
    Accept-Encoding: gzip, deflate, br
    Referer: https://localhost:9443/fediz-idp/federation/up?wa=wsignin1.0&wreply=https%3A%2F%2Flocalhost%3A8443%2Ffedizhelloworld%2Fsecure%2Ffedservlet&wtrealm=urn%3Aorg%3Aapache%3Acxf%3Afediz%3Afedizhelloworld&wct=2018-02-15T13%3A07%3A31.334Z&wctx=96466346-2237-4331-a43b-2c1d71ab317f&homeRealm=urn%3Aorg%3Aapache%3Acxf%3Afediz%3Aidp%3Arealm-A&execution=e1s1&_eventId_submit=Select+Home+Realm
    Content-Type: application/x-www-form-urlencoded
    Content-Length: 7914
    Cookie: JSESSIONID=AA103BDD94C8C0652582ABBE13E2C724
    Connection: keep-alive
    Upgrade-Insecure-Requests: 1

    HTTP/1.1 401 Unauthorized
    Server: Apache-Coyote/1.1
    Content-Type: text/html;charset=utf-8
    Content-Language: en
    Content-Length: 951
    Date: Thu, 15 Feb 2018 13:07:44 GMT

    And the parameter has Roles, ,certificate and rest of the expected data.

    Is it that the RP( Federation Filter) does not have the right cert installed.

  11. This comment has been removed by the author.

  12. Apologies for the unformatted text. SAML response has the roles - User, Manager,Admin along with other data.

  13. Hi Colm,
    Is there a way I can check the issue at RP instance, I am unable to enable the log4j for fediz lib to check for any errors as well.
    Any assistance would be helpful, as we are planning to deploy this on cloud .

  14. (X509Certificate[])req.getAttribute("javax.servlet.request.X509Certificate") is returning null. Causing 401 error. Need to further check why the certificate is not set in the request

  15. I don't think the X509Certificate returning null should cause 401, that's only used for when the SAML Token is "holder-of-key". I wrote a blog post here showing how to enable FINE logging for the plugin - it should tell you what the error is:

  16. Hi Colm,

    I have been trying to use Apache CXF Fediz v1.4.5 based on the documentation and example app available ( and fedizhelloworld app). Everything seemed to work fine (redirect to IdP occurred, user got authenticated and token was generated) except that I was getting 401 Unauthorized error. This is how I found your blog.

    I then tried to redo everything following all the steps in and also used your docker image for Tomcat and fedizhelloworld example app. But I am getting the same 401 Unauthorized error.

    Could you please take a look at a snip from the plugin logs below to see if it provides any details regarding the problem?

    It looks like it fails to validate SAML response hence the problem -

    <message>Issuer 'null' not validated in keystore '/usr/local/tomcat/keycloak.cert'</message>
    <message>SAML Response is not trusted</message>
    <message>The security token could not be authenticated or authorized</message>
    <message>org.apache.wss4j.common.ext.WSSecurityException: The security token could not be authenticated or authorized</message>

    <message>Federation processing failed: The request was invalid or malformed</message>

    Thank you for looking.


  17. Are you following the instructions in section 2.3 here ( Note the bit about -----BEGIN CERTIFICATE----- / -----END CERTIFICATE-----" tags.

  18. Thank you for a quick response, Colm!

    Yes, the /usr/local/tomcat/keycloak.cert file has -----BEGIN CERTIFICATE----- and -----END CERTIFICATE-----. I can try and recreate it if you think malformed (and/or copy/past) signing cert can lead to such error.

    Does the message "Issuer 'null' not validated in keystore '/usr/local/tomcat/keycloak.cert'" look ok to you? It sounds like the issuer id is considered to be null even though the "Received response:..." above this message has it set. Here is a snip from the "Received response:..." -

    <samlp:Response Destination="https://localhost:9443/fedizhelloworld/secure/fedservlet"
    IssueInstant="2019-03-26T15:46:33.485Z" Version="2.0"
    xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion" xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol">


  19. Colm,

    I have recreated the signer certificate and everything works fine now. I think I used the wrong signing cert, my bad. Apologize for taking up your time.

    Thank you for your help!