<h3>Fediz 1.1 introduces Federation across Security Domains (Part 2)</h3>

In the first blog on this topic I explained how to add security domains to the Fediz STS which is based on the Apache CXF STS. This blog focuses on how to set up the Fediz IDP thus you can access an application but authenticate either against the requestor IDP of realm A or realm B.

I posted a blog some time back about WS-Federation across several companies and explained the benefits and key requirements here. I recommend to read that blog first.

Here a quick summary of the goals and requirements by introducing WS-Federation for Web Application Single-Sign-On:

• Application doesn't care about authentication
• Application doesn't care against which authentication system the user has been authenticated
• Application doesn't care where the user attributes are coming from
• Application has got a trusted relationship with a single IDP/STS instance which ensures the user is authenticated and the user attributes are provided in one syntax and semantic independent from which source they are coming from
• Application must be able to enforce certain authentication methods (ex. strong authentication)
• Application must be able to enforce certain user attributes in the security token

In the last blog, we've prepared the STS which is responsible to issue tokens for the two realms REALMA and REALMB. Further, the STS is able to federate between the two realms by mapping the identities (attribute type of Relationship bean configuration. This means, a person must have an identity in realm A (ex. bob) and an identity in realm B (ex. BOB). To keep it simple, the mapping is based to lowercase the username. Another option is to federate/map the claims which doesn't require that a person must have an identity in both realms. This requires more effort to set up a demo and might be provided in the future for illustration purposes, but all required functionality and extension points are available.

Notes:

• The Fediz IDP doesn't support yet to host several realms in one WAR file. Therefore, two Servlet Containers must be set up to deploy the IDP war file.

  In B2B scenarios this won't be required anyway as the B2B partner has got an IDP attached to its realm as well as the application service provider has got an IDP attached to its realm. It might make sense in scenarios where the company itself has got more than one authentication systems in place.

• For ease of use, the Fediz IDP and Fediz STS are deployed into the same Serlvet Container and therefore accessed with the same TCP port. Due to the fact, that the Fediz STS supports both realms in one WAR file, the Fediz STS WAR fediz-idp-sts.war is just deployed twice.

Install Apache CXF Fediz IDP

The Fediz IDP is provided as part of the subproject Fediz in Apache CXF. The new version provides the Apache Maven profile realm-a (Default) and realm-b which packages the IDP either for security domain REALM A and REALM B.

You can either download the sources of the Fediz IDP from the following location

git clone git://git.apache.org/cxf-fediz.git

or

svn co https://svn.apache.org/repos/asf/cxf/fediz/trunk

You can build the IDP for realm A with the following Maven command

mvn clean install -Prealm-a

The IDP is packaged as a WAR file at services/idp/target/fediz-idp.war

You can build the IDP for realm B with the following Maven command

mvn clean install -Prealm-b

The IDP is packaged as a WAR file at services/idp/target/fediz-idp-remote.war

Note: The WAR file and therefore the servlet context name is not fediz-idp but fediz-idp-remote. This is required because cookies are bound to the hostname (ex. localhost) and the path (ex. fediz-idp). If the servlet context is the same, cookies are overwritten between the two IDP instances. There are also other options to bound the WAR file with a specific servlet context name but this relies on the Servlet Container provider.

Last option is to download the archive from the snapshot maven repository. Keep in mind that this IDP is built with the profile realm-a. Only the following files must be updated for realm B:

• WEB-INF/applicationContext.xml

  Change

  <import resource="idp-config-realma.xml" />

  to

  <import resource="idp-config-realmb.xml" />

• WEB-INF/classes/realm.properties

  Change

  realm.STS_URI=REALMA

  to

  realm.STS_URI=REALMB

• WEB-INF/web.xml

  Change

  <param-value>urn:org:apache:cxf:fediz:idp:realm-A</param-value>

  to

  <param-value>urn:org:apache:cxf:fediz:idp:realm-B</param-value>

Note: The built WAR files require that IDP Realm A is deployed into a Servlet Container running on port 9443 and IDP Realm B is deployed into a Servlet Container running on port 12443. If you want to change that then you must update the file WEB-INF/classes/realm.properties or at source location services/idp/src/main/resources/.

Update Relying Party (Application)

I assume you have installed fedizhellworld example into a supported Serlvet Container. If not, install the fedizhellworld example based on the README.txt.

The following steps must be processed to establish the trust with the IDP Realm A:

• Issuer URL must be Realm A (ex. https://localhost:9443/fediz-idp/federation )
• Signer certificate of Realm A must be imported into the truststore because new certificates are used for realm A and realm B
  You can either copy the file stsstore.jks from the STS archive within WEB-INF/classes or copy the file realma.cert from the STS archive from the same location.

Run the demo

You have now deployed the IDP realm A (fediz-idp.war) into a Servlet Container listening on port 9443 and IDP realm B (fediz-idp-remote.war) into a Servlet Container listening on port 12443. Finally, the Relying Party has been updated to trust the IDP Realm A.

When you now access the fedizhelloworld application (ex. https://localhost:8443/fedizhelloworld/secure/fedservlet) you get redirected to the IDP Realm A and the following web page is shown

You can now choose in which domain you would like to authenticate. Choose the IDP in the list and click Select Home Realm. If you choose Realm B you get redirected to IDP Realm B and username/password popup is shown (use uppercase username and passwords) or IDP Realm A shows username/password popup (use lowercase username and passwords).

If you choose Realm B and enter the user ALICE and the password ECILA you finally see the user alice (lowercase) shown in the application. You know why? Exactly, the STS does the identity mapping when the REALM A is requested a SAML token for the application fedizhelloworld on-behalf-of the SAML token issued by Realm B.

Notes

• The IDP will ask you only once to choose your home realm. The choice is stored in the cookie FEDIZ_HOME_REALM
• If your home realm is realm B and you're successfully authenticated, the IDP realm A won't redirect you to realm B the next time, as the original SAML token of realm B is cached in realm A.

IDP Configurations

The design of the IDP changed (Spring Web Flow and Spring Security), new features are implemented and thus the configuration is completely different to version 1.0. I don't want to go into too much details in this blog, instead I'll update the Apache CXF Fediz Wiki soon.

Use form based login

Change the spring security configuration in WEB-INF/security-config.xml and set the following configuration:

    <!--<security:http-basic />-->
    <security:form-login />

Configure an additional Relying Party

The main configuration file of the IDP is idp-config-realma.xml. This file contains configurations for the IDP, trusted IDPs and Relying Parties.

If you want to configure an additional application add a ServiceConfig bean and add it to the map services in the IDP configuration bean.

  <bean id="idp-realmA" class="org.apache.cxf.fediz.service.idp.model.IDPConfig">
    ...
    <property name="services">
      <util:map>
        <entry key="urn:org:apache:cxf:fediz:fedizhelloworld" value-ref="srv-fedizhelloworld" />
      </util:map>
    </property>
    ...

  <bean id="srv-fedizhelloworld" class="org.apache.cxf.fediz.service.idp.model.ServiceConfig">
    <property name="realm" value="urn:org:apache:cxf:fediz:fedizhelloworld" />
    <property name="protocol" value="http://docs.oasis-open.org/wsfed/federation/200706" />
    <property name="serviceDisplayName" value="Fedizhelloworld" />
    <property name="serviceDescription" value="Web Application to illustrate WS-Federation" />
    <property name="role" value="ApplicationServiceType" />
    <property name="tokenType" value="http://docs.oasis-open.org/wss/oasis-wss-saml-token-profile-1.1#SAMLV2.0" />
    <property name="lifeTime" value="3600" />
    <property name="requestedClaims">
      <util:list>
        <bean class="org.apache.cxf.fediz.service.idp.model.RequestClaim">
          <property name="claimType" value="http://schemas.xmlsoap.org/ws/2005/05/identity/claims/givenname" />
          <property name="optional" value="false" />
        </bean>
        <bean class="org.apache.cxf.fediz.service.idp.model.RequestClaim">
          <property name="claimType" value="http://schemas.xmlsoap.org/ws/2005/05/identity/claims/surname" />
          <property name="optional" value="false" />
        </bean>
        <bean class="org.apache.cxf.fediz.service.idp.model.RequestClaim">
          <property name="claimType" value="http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress" />
          <property name="optional" value="false" />
        </bean>
        <bean class="org.apache.cxf.fediz.service.idp.model.RequestClaim">
          <property name="claimType" value="http://schemas.xmlsoap.org/ws/2005/05/identity/claims/role" />
          <property name="optional" value="true" />
        </bean>
      </util:list>
    </property>
  </bean>

It's important that the attribute realm matches with the realm configured in the application (fediz-config.xml). The attributes tokenType, lifeTime and requestedClaims are optional. Only the protocol defined in the above bean is supported by the IDP and therefore the default value. The remaining attributes are ignored but used in the future like the Web GUI.

Configure an additional Trusted IDP

If you want to configure an additional trusted IDP add a TrustedIDPConfig bean and add it to the map trustedIDPs in the IDP configuration bean.

  <bean id="idp-realmA" class="org.apache.cxf.fediz.service.idp.model.IDPConfig">
    ...
    <property name="trustedIDPs">
      <util:map>
        <entry key="urn:org:apache:cxf:fediz:idp:realm-B" value-ref="trusted-idp-realmB" />
      </util:map>
    </property>
    ...

  <bean id="trusted-idp-realmB" class="org.apache.cxf.fediz.service.idp.model.TrustedIDPConfig">
    <property name="realm" value="urn:org:apache:cxf:fediz:idp:realm-B" />
    <property name="cacheTokens" value="true" />
    <property name="url" value="https://localhost:${realmB.port}/fediz-idp-remote/federation" />
    <property name="certificate" value="realmb.cert" />
    <property name="trustType" value="PEER_TRUST" />  <!-- Required for Fediz Core, Process SignInResponse -->
    <property name="protocol" value="http://docs.oasis-open.org/wsfed/federation/200706" />
    <property name="federationType" value="FederateIdentity" /> <!-- Required for STS Relationship -->
    <property name="name" value="REALM B" />
    <property name="description" value="IDP of Realm B" />
  </bean>

It's important that the filename of the PEM encoded certificate is configured which has been used to sign the SAML token by the trusted IDP. The attribute name is required for informational purposes whereas the remaining attributes are ignored but used in the future like the Web GUI.

Even there is much more to say I finish this post and write about other features of the new Fediz IDP in the near future.

Please post feedback and ideas to the CXF mailing list.

Thank you for all support and feedback!