Federation of user registries

User registry federation is used when user and group information is spread across multiple registries. For example, the information might be in two different LDAPs, in two subtrees of the same LDAP, in a file, or the users are of a system. The information might even be in a custom user data repository. With registries federated, you can search and use these distributed user information in a unified manner with continuous store of information. Using federated registry, you can use the unified view for authentication and authorization of users in Liberty.

Note: Quick start security (quickStartSecurity) cannot be federated with other user registries such as the LDAP, basic, SAF, and custom registries.

How are user registries federated?

LDAP registries are federated by default. If more than one LDAP registry is configured in the server.xml, then the registries are automatically federated and no additional configuration is needed. They can be two separate LDAPs or two subtrees in the same LDAP.
If one or more LDAP registries are configured with one or more of basic, SAF, or custom registries, those registries are also federated without any additional configuration. The following example shows a basic registry federated with an LDAP:
<server description="Federation">
    <featureManager>
        <feature>appSecurity-2.0</feature>
        <feature>servlet-3.0</feature>
	 <feature>ldapRegistry-3.0</feature>
    </featureManager>

    <basicRegistry id="basic" realm="SampleBasicRealm">
        <user name="admin" password="password" />
        <user name="user1" password="password" />
            <user name="user2" password="password" />
        <group name="memberlessGroup" />
        <group name="adminGroup">
            <member name="admin"/>
        </group>
        <group name="users">
            <member name="user1"/>
            <member name="user2"/>
        </group>
    </basicRegistry>

    <ldapRegistry id="LDAP1" realm="SampleLdapIDSRealm" host="LDAPHOST1.ibm.com" port="389" ignoreCase="true"
	baseDN="o=ibm,c=us"
	ldapType="IBM Tivoli Directory Server"
	searchTimeout="8m"
	recursiveSearch="true">
    </ldapRegistry>
</server>
If you want to federate two basic registries or a basic registry with a SAF or custom registry, you can do so by including the federatedRegistry-1.0 in addition to the appSecurity-2.0 feature as shown in the following example:
    <feature>appSecurity-2.0</feature>
    <feature>federatedRegistry-1.0</feature>
The following example shows the federation of two basic registries:
<server description="Federation">
    <featureManager>
        <feature>appSecurity-2.0</feature>
        <feature>federatedRegistry-1.0</feature>
    </featureManager>

    <basicRegistry id="basic1" realm="SampleBasicRealm1">
        <user name="admin" password="password" />
        <user name="user1" password="password" />
            <user name="user2" password="password" />
        <group name="memberlessGroup" />
        <group name="adminGroup">
            <member name="admin"/>
        </group>
        <group name="users">
            <member name="user1"/>
            <member name="user2"/>
        </group>
    </basicRegistry>

    <basicRegistry id="basic2" realm="SampleBasicRealm2">
        <user name="user3" password="password123" />
        <user name="user4" password="password123" />
        <group name="memberlessGroup2" />
        <group name="users2">
            <member name="user3"/>
            <member name="user4"/>
        </group>
    </basicRegistry>
</server>
Basic registries can be added to a customized federated repository. A basic registry is added by defining the participatingBaseEntry name field in the federatedRepository element. The participating base entry for a basic registry is the organization attribute set to the realm name of the basic registry. The following example shows a customized federation of two basic registries:
<federatedRepository>
    <primaryRealm name="PrimaryRealm">
        <participatingBaseEntry name="o=SampleBasicRealm1"/>
        <participatingBaseEntry name="o=SampleBasicRealm2"/>
    </primaryRealm>
</federatedRepository>
Custom registries can also be added to a customized federated repository. A custom registry is added by defining the participatingBaseEntry name field in the federatedRepository element. The participating base entry for a custom registry is the organization attribute set to the realm name of the custom registry. The following example shows the federation of a customized entry:
<federatedRepository>
    <primaryRealm name="PrimaryRealm">
        <participatingBaseEntry name="o=customRegistryRealm1"/>
    </primaryRealm>
</federatedRepository>

To federate an SAF registry with one or more non-SAF registries with SAF authorization enabled, you must configure distributed identity filters to map any non-SAF users to an SAF user ID. The following example illustrates an SAF registry that is federated with an LDAP registry and with distributed identity mapping enabled. The primaryRealm name is specified on the federatedReposity element so that any RACMAP profiles that are defined to map the LDAP users to SAF user ID must specify REGISTRY(NAME('FEDREALM').

<server description="Federated SAF and LDAP">
          <featureManager>        
          <feature>appSecurity-2.0</feature>        
          <feature>federatedRegistry-1.0</feature>        
          <feature>zosSecurity-1.0</feature>  
          <feature>ldapRegistry-3.0</feature>
          </featureManager>
        <federatedRepository>   
              <primaryRealm name="FEDREALM">
              </primaryRealm>
        </federatedRepository>

 <!-- SAF user registry -->    
 <safRegistry id="saf" realm="SAFREALM" /> 
 <safAuthorization id="saf" racRouteLog="ASIS" /> 
 <safCredentials unauthenticatedUser="WSGUEST"
                            profilePrefix="BBGZDFLT"
                            mapDistributedIdentities="true" />    
 <safRoleMapper profilePattern="%profilePrefix%.%resource%.%role%"
                            toUpperCase="false" />

  <ldapRegistry id="LDAP1" realm="LDAPREALM" 
      ldapType="IBM Tivoli Directory Server"
      host="LDAP1HOST.ibm.com" port="389"        
      baseDN="o=ibm,c=us"  
      searchTimeout="8m"
      ignoreCase="true"        
      bindDN="uid=ldapadm,cn=users,o=ibm,c=us"        
      bindPassword="ldapadmpw"  
      sslEnabled="false">        
      <idsFilters            
          userFilter="(&amp;(uid=%v)(objectclass=inetOrgPerson))"            
          groupFilter="(&amp;(cn=%v)(objectclass=groupOfUniqueNames))"
          userIdMap="*:uid"            
          groupIdMap="*:cn"            
          groupMemberIdMap="groupOfUniqueNames:uniquemember">         
          </idsFilters>  
   </ldapRegistry>
</server>

Icon that indicates the type of topic Concept topic

File name: cwlp_repository_federation.html