Fediz IDP 1.1Page edited by Oliver WulffChanges (1)
Full ContentFediz IDPThe Release 1.1 introduces the following new feature:
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 for validating credentials, getting the requested claims data and issuing a SAML token. There is no easy way for Web browsers to issue SOAP requests to the STS directly, necessitating the second component, an IDP WAR (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 a customized CXF STS configured to support standard Federation use cases demonstrated by the examples. The Fediz STS has been enhanced to support two realms *Realm-A* and *Realm-B* with the following set of users:
The Fediz IDP doesn't support several realms within one WAR which requires to build a Fediz IDP WAR for Realm A (default, shipped with Fediz Distribution) and Realm B. See below how to build a Fediz IDP WAR for a specific realm. InstallationThe Fediz IDP has been tested with Tomcat 6 and 7 but 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: CATALINA_HOME=/path/to/second/tomcat $CATALINA_HOME/bin/startup.sh
Here is a sample snippet for showing the configuration of the above three values:
<Server port="9005" shutdown="SHUTDOWN">
...
<!-- http configuration -->
<Connector port="9080" protocol="HTTP/1.1"
connectionTimeout="20000"
redirectPort="9443" />
...
<!-- https configuration -->
<Connector port="9443" protocol="HTTP/1.1" SSLEnabled="true"
maxThreads="150" scheme="https" secure="true"
keystoreFile="idp-ssl-server.jks"
keystorePass="tompass" sslProtocol="TLS" />
...
<Connector port="9009" protocol="AJP/1.3" redirectPort="9443" />
...
</Server>
The keystoreFile is relative to $CATALINA_BASE. See here for the Tomcat 7 configuration reference. This page also describes how to create certificates. 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. Build the IDP WARThe Fediz 1.1 distribution ships one Fediz IDP WAR built for Realm-A by default. The distribution also contains the IDP and STS sources with two Maven Profiles realm-a and realm-b. More information is provided in the README.txt here Once you deploy the IDP WAR files to your Tomcat installation (<catalina.home>/webapps), you should be able to see the Fediz STS from a browser at http://localhost:9080/fediz-idp-sts/STSService?wsdl , assuming you're using port 9080 as listed above. ConfigurationYou can manage the users, their claims and the claims per application in the IDP. User and passwordThe users and passwords are configured in a Spring configuration file in webapps/fediz-idp-sts/WEB-INF/passwords.xml. The following users are already configured for the Realm A and can easily be extended.
<util:map id="passwords">
<entry key="alice"
value="ecila" />
<entry key="bob"
value="bob" />
<entry key="ted"
value="det" />
</util:map>
User ClaimsThe 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:
<util:map id="userClaimsREALMA">
<entry key="alice"
value-ref="REALMA_aliceClaims" />
<entry key="bob"
value-ref="REALMA_bobClaims" />
<entry key="ted"
value-ref="REALMA_tedClaims" />
</util:map>
<util:map id="REALMA_aliceClaims">
<entry key="http://schemas.xmlsoap.org/ws/2005/05/identity/claims/givenname"
value="Alice" />
<entry key="http://schemas.xmlsoap.org/ws/2005/05/identity/claims/surname"
value="Smith" />
<entry key="http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress"
value="[email protected]" />
<entry key="http://schemas.xmlsoap.org/ws/2005/05/identity/claims/role"
value="User" />
</util:map>
The claim id's are configured according to Section 7.5 in the specification Identity Metasystem Interoperability. The mapping of claims to a SAML attribute statement are described in Section 7.2. Application claimsNote: The configuration file RPClaims.xml has been replaced The required claims per relying party are configured in the new IDP configuration file idp-config-<realm>.xml which has been enhanced to support other configuration parameters as well:
<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>
Configure LDAP directoryThe Fediz IDP can be configured to attach an LDAP directory to authenticate users and to retrieve claims information of users. Username and password authenticationWSS4J 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):
myldap {
com.sun.security.auth.module.LdapLoginModule REQUIRED
userProvider=ldap://ldap.mycompany.org:389/OU=Users,DC=mycompany,DC=org"
authIdentity="cn={USERNAME},OU=Users,DC=mycompany,DC=org"
useSSL=false
debug=true;
};
You can get more information about this LoginModule here. In this example, all the users are stored in the organization unit Users within mycompany.org. The configuration filename can be chosen, e.g. jaas.config. The filename must be configured as a JVM argument. JVM related configurations for Tomcat can be done in the file setenv.sh/bat located in directory tomcat/bin. This script is called implicitly by catalina.bat/sh and might look like this for UNIX: #!/bin/sh JAVA_OPTS="-Djava.security.auth.login.config=/opt/tomcat/conf/jaas.config" export JAVA_OPTS Next, the STS endpoint has to be configured to use the JAAS LoginModule which is accomplished by the JAASUsernameTokenValidator.
<bean
class="org.apache.ws.security.validate.JAASUsernameTokenValidator"
id="jaasUTValidator">
<property name="contextName" value="myldap"/>
</bean>
<jaxws:endpoint id="transportSTSUT"
endpointName="ns1:TransportUT_Port"
serviceName="ns1:SecurityTokenService"
xmlns:ns1=http://docs.oasis-open.org/ws-sx/ws-trust/200512/
wsdlLocation="/WEB-INF/wsdl/ws-trust-1.4-service.wsdl"
address="/STSServiceTransportUT"
implementor="#transportSTSProviderBean">
<jaxws:properties>
<entry key="ws-security.ut.validator"
value-ref="jaasUTValidator"/>
</jaxws:properties>
</jaxws:endpoint>
The property contextName must match the context name defined in the JAAS configuration file which is myldap in this example. Claims managementWhen 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. You configure which claim URI maps to which LDAP user attribute. The implementation uses the Spring Ldap Module (LdapTemplate). The following example illustrate the changes to be made in webapps/fediz-idp-sts/WEB-INF/cxf-transport.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>
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:
Stop watching space
|
Change email notification preferences
View Online
|
View Changes
|
- [CONF] Apache CXF > Fediz IDP 1.1 Oliver Wulff (Confluence)
- [CONF] Apache CXF > Fediz IDP 1.1 Oliver Wulff (Confluence)
- [CONF] Apache CXF > Fediz IDP 1.1 Oliver Wulff (Confluence)
- [CONF] Apache CXF > Fediz IDP 1.1 Oliver Wulff (Confluence)
- [CONF] Apache CXF > Fediz IDP 1.1 Oliver Wulff (Confluence)
- [CONF] Apache CXF > Fediz IDP 1.1 Oliver Wulff (Confluence)
