Versions Compared

Old Version 2

changes.mady.by.user Oliver Wulff

Saved on

compared with

New Version Current

changes.mady.by.user Colm O hEigeartaigh

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

Fediz IDP

Note: This document describes the Fediz IdP in the 1.0 release. For more recent releases please go here instead.

(warning) Under construction

...

The Fediz Identity Provider (IDP) consists of two WAR files. One is the Security Token Service (STS) component, fediz-idp-sts.war, which is responsible to validate for validating credentials, getting the requested claims data and issues issuing a SAML token. There is no easy way for Web browsers to issue SOAP requests to the STS directly. The , necessitating the second component is the , an IDP WAR which adapts the browser to (fediz-idp.war) which allows browser-based applications to interact with the STS. The communication between the browser and the IDP must be performed within the confines of the base HTTP 1.1 functionality and conform as closely as possible to the WS-Trust protocols semantic.

The Fediz STS is based on the a customized CXF STS configured to support the standard Federation use cases required demonstrated by the examples.

Installation

The Fediz IDP has been tested with Tomcat 6 and 7 but there are no reasons why it shouldn't work in should be able to work with any commercial JEE application server.

It's recommended to set up a dedicated (separate) Tomcat instance for the IDP compared to the one hosting the RP (relying party) applications. Using one deployment of Tomcat with multiple CATALINA_BASE instances, as described here is one option but note any libs in $CATALINA_HOME/lib folder will be shared throughout each of the activated CATALINA_BASE instances. Another probably simpler alternative is to copy your Tomcat folder into a second location and edit its conf/server.xml file and change port values (discussed below) so they don't conflict with the original Tomcat installation.

To start and stop this second Tomcat instance, it is perhaps easiest to create small startup.sh and shutdown.sh scripts that temporarily redefine $CATALINA_HOME from the first to the second instance, for example:

Code Block

CATALINA_HOME=/path/to/second/tomcat
$CATALINA_HOME/bin/startup.sh

and

Code Block

CATALINA_HOME=/path/to/second/tomcat
$CATALINA_HOME/bin/shutdown.sh

If you're using the one Tomcat with multiple instance option, it's $CATALINA_BASE instead that will need to be redefined above.

Tomcat server.xml configuration

The Fediz examples use the following TCP ports to interact with the IDP/STS:Tomcat port values for the IDP/STS, defined in the conf/server.xml file. We use ports different from the Tomcat defaults so as not to conflict with the Tomcat instance running the RP applications.

  • HTTP port: 9080 (used for maven Maven deployment, mvn tomcat:redeploy)
  • HTTPS port: 9443 (where IDP and STS are accessed)

The Tomcat HTTP(s) configuration is done in conf/server.xml.

  • Server port (for shutdown and other commands): 9005

Here This is a sample snippet for an HTTPS configurationshowing the configuration of the above three values:

Code Block
xml
xml
<Server port="9005" shutdown="SHUTDOWN">
...

   <!-- http configuration -->
   <Connector port="94439080" protocol="HTTP/1.1" SSLEnabled
        connectionTimeout="true20000"
        redirectPort="9443" />

   ...

   <!-- https configuration -->
   <Connector maxThreadsport="1509443" schemeprotocol="httpsHTTP/1.1" secureSSLEnabled="true"
        maxThreads="150" scheme="https" secure="true"
        keystoreFile="tomcatKeystoretomcat-idp.jks"
        keystorePass="tompass" sslProtocol="TLS" />
   ...
 
   <Connector port="9009" keystorePassprotocol="tompassAJP/1.3" sslProtocolredirectPort="TLS9443" />

...
</Server>

The keystoreFile is relative to catalina home$CATALINA_HOME. See here for the Tomcat 7 configuration reference. This page also describes how to create certificates.

Production: It's highly recommended to deploy certificates signed by a Certificate Authority

Sample Tomcat keystores (not for production use, but useful for demoing Fediz and running the sample applications) are provided in the examples/samplekeys folder of the Fediz distribution.

To establish trust, there are significant keystore/truststore requirements between the Tomcat instances and the various web applications (IDP, STS, Relying party applications, third party web services, etc.) See this page for more details, it lists the trust requirements as well as sample scripts for creating your own (self-signed) keys.

Warning: All sample keystores provided with Fediz (including in the WAR files for its services and examples) are for development/prototyping use only. They'll need to be replaced for production use, at a minimum with your own self-signed keys but strongly recommended to use third-party signed keys.

Once you deploy the IDP Deploy the WAR files to your Tomcat installation (<catalina.home>/webapps) and ensure that Tomcat is started thus the WAR files get deployed, you should be able to see the Fediz STS from a browser at http://localhost:9080/fediz-idp-sts/STSService?wsdl (note that prior to 1.0.3 the war name is actually "fedizidpsts"), assuming you're using port 9080 as listed above.

Configuration

You can manage the users, their claims and the claims per application in the IDP.

User and password

The users and passwords are configured in a spring Spring configuration file in webapps/fediz-idp-sts/WEB-INF/passwords.xml. The following users are already configured and can easily be extended.

Code Block
xml
xml
    <util:map id="passwords">
        <entry key="alice"
            value="ecila" />
        <entry key="bob"
            value="bob" />
        <entry key="ted"
            value="det" />
    </util:map>
User Claims

The claims of each user are configured in a spring configuration file webapps/fediz-idp-sts/WEB-INF/userClaims.xml. The following claims are already configured:

...

The claim id's are configured according to chapter Section 7.5 in the specification Identity Metasystem Interoperability. The mapping of claims to a SAML attribute statement are described in chapter Section 7.2.

Application claims

The required claims per relying party are configured in the webapps/fediz-idp/WEB-INF/RPClaims.xml. The XML file has the following structure:

...

The key of each map entry must match with the wtrealm paramater in the redirect triggered by the relying party. The required claims for the different type of applications are grouped in beans which are a list of String Strings as illustrated in claimsWsfedhelloworld.

...

The JIRA issue FEDIZ-1 will provide another option to manage the required claims on the Relying Party side.

Configure LDAP directory

The Fediz IDP can be configured to attach an LDAP directory to authenticate users and to retrieve claims information of users.

Username and password authentication

WSS4J supports username/password authentication using JAAS. The JDK provides a JAAS LoginModule for LDAP which can be configured as illustrated here in a sample jaas configuration (jaas.config):

...

Next, the STS endpoint has to be configured to use the JAAS LoginModule which is acomplished accomplished by the JAASUsernameTokenValidator.

...

The property contextName must match with the context name defined in the JAAS configuration file which is myldap in this example.

Claims management

When a STS client (IDP) requests a claim, the ClaimsManager in the STS checks every registered ClaimsHandler who can provide the data of the requested claim. The CXF STS provides org.apache.cxf.sts.claims.LdapClaimsHandler which is a claims handler implementation to get claims from user attributes in a LDAP directory.

...

Code Block
xml
xml
<util:list id="claimHandlerList">
  <ref bean="ldapClaimsHandler" />
</util:list>

<bean id="contextSource"
   class="org.springframework.ldap.core.support.LdapContextSource">
  <property name="url" value="ldap://ldap.mycompany.org:389" />
  <property name="userDn"
    value="CN=techUser,OU=Users,DC=mycompany,DC=org" />
  <property name="password" value="mypassword" />
</bean>

<bean id="ldapTemplate"
   class="org.springframework.ldap.core.LdapTemplate">
  <constructor-arg ref="contextSource" />
</bean>

<util:map id="claimsToLdapAttributeMapping">
  <entry
key="http://schemas.xmlsoap.org/ws/2005/05/identity/claims/givenname"
value="givenName" />
  <entry key="http://schemas.xmlsoap.org/ws/2005/05/identity/claims/surname"
value="sn" />
  <entry
key="http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress"
value="mail" />
  <entry key="http://schemas.xmlsoap.org/ws/2005/05/identity/claims/country"
value="c" />
</util:map>

<bean id="ldapClaimsHandler"
    class="org.apache.cxf.sts.claims.LdapClaimsHandler">
  <property name="ldapTemplate" ref="ldapTemplate" />
  <property name="claimsLdapAttributeMapping"
            ref="claimsToLdapAttributeMapping" />
  <property name="userBaseDN"
      value="OU=Users,DC=mycompany,DC=org" />
</bean>

Configure CA certificates

...

You must deploy the library for the spring ldap module and its dependencies. The POM of the spring ldap module is available here.
You can add the dependency to spring ldap module to the Fediz STS POM, add the above configuration and rebuild the STS component or do the configuration in the deployed STS directly and add the following JAR files:
  • lang-2.1.0.jar
  • ldapbp-1.0.jar
  • spring-ldap-1.2.jar