Federated repositories

Federated repositories enable you to use multiple repositories with WebSphere Application Server. These repositories, which can be file-based repositories, LDAP repositories, or a sub-tree of an LDAP repository, are defined and theoretically combined under a single realm. All of the user repositories that are configured under the federated repository functionality are invisible to WebSphere Application Server.

When you use the federated repositories functionality, all of the configured repositories, which you specify as part of the federated repository configuration, become active. It is required that the user ID, and the distinguished name (DN) for an LDAP repository, be unique in multiple user repositories that are configured under the same federated repository configuration. For example, there might be three different repositories that are configured for the federated repositories configuration: Repository A, Repository B, and Repository C. When user1 logs in, the federated repository adapter searches each of the repositories for all of the occurrences of that user. If multiple instances of that user are found in the combined repositories, an error message displays.

In addition, the federated repositories functionality in WebSphere Application Server supports the logical joining of entries across multiple user repositories when the Application Server searches and retrieves entries from the repositories. For example, when an application calls for a sorted list of people whose age is greater than twenty, WebSphere Application searches all of the repositories in the federated repositories configuration. The results are combined and sorted before the Application Server returns the results to the application.

[z/OS] Restrictions:
Unlike the local operating system, standalone LDAP registry, or custom registry options, federated repositories provide user and group management with read and write capabilities. When you configure federated repositories, you can use one of the following methods to add, create, and delete users and groups:
Important: If you configure multiple repositories under the federated repositories realm, you must also configure supported entity types and specify a base entry for the default parent. The base entry for the default parent determines the repository location where entities of the specified type are placed on write operations by user and group management. See Configuring supported entity types in a federated repository configuration for details.

If you do not configure the federated repositories functionality or do not enable federated repositories as the active repository, you cannot use the user management capabilities that are associated with federated repositories. You can configure an LDAP server as the active user registry and configure the same LDAP server under federated repositories, but not select federated repositories as the active user repository. With this scenario, authentication takes place using the LDAP server, and you can use the user management functionality for the LDAP server that is available for federated repositories.

The following table compares the federated repository functionality that is available in WebSphere Application Server Version 6.1 with the registry functionality that remains unchanged from previous versions of the Application Server.
Table 1. Federated repositories versus user registry implementations
Federated repositories User registry

Supports multiple types of repositories such as file-based, LDAP, database, and custom. In WebSphere Application Server Version 6.1, file-based and LDAP repositories are supported by the administrative console. However, the federated repositories functionality does not support local operating system implementations.

[Fix Pack 27 or later] Update: The federated repositories functionality supports local operating system implementations. Prior to this service release, these implementations are not supported.

For database and custom repositories, you can use the wsadmin command-line interface or the configuration application programming interfaces (API).

[z/OS] Restriction: WebSphere Application Server federated repositories DO NOT support a z/OS LDAP server with an SDBM backend (resource access control facility (RACF)).
Supports multiple types of registries such as the local operating system, a standalone LDAP registry, and a standalone custom registry.
Supports multiple repositories in a realm within a cell. Supports one registry only in a realm within a cell.
Provides read and write capabilities for the repositories that are defined in the federated repository configuration. Provides read only capability for the registries.
Provides account and password policy support as defined by the registry type. However, this support is not provided by the federated repository functionality. Provides account and password policy support as defined by the registry type.
Supports identity profiles. Does not support identity profiles.
Uses the custom UserRegistry implementation. Uses the custom UserRegistry implementation.

[z/OS] When using federated repository security enabled out-of-the-box, a RACF keyring is created for the daemon's userid. However, the certificates from this keyring are not automatically added to the WebSphere keyrings. Since the certificates in the RACF keyring are not trusted by WebSphere, error messages will appear.

[z/OS] Follow these steps to add the daemon's signer certificate to the cell's trust store:
  1. Get the daemon's SSL port and host name. In the administrative console, click System Administration > Node Groups > DefaultNodeGroup > z/OS location service. Make a note of the SSL port and the host name.
  2. Add the signer certificate to the trust store. In the administrative console, do the following:
    • Click Security > SSL ceritifcate and key management.
    • Under Related Items, click Key stores and certificates..
    • Click CellDefaultTrustStore.
    • Click Signer Certificates > Click on Retrieve from port. Enter the daemon's SSL port and host name, and any name for the alias.
    • Click Retrieve signer information and then click OK.
  3. Synchronize the nodes, and stop all node agents in the cell. From a telnet session, run the following command:
    syncNode.sh <dmgrHostName> <dmgrPort> -user <username> -password <password>
  4. Restart all processes in the cell



Related tasks
Managing the realm in a federated repository configuration
Concept topic Concept topic    

Terms and conditions for information centers | Feedback

Last updatedLast updated: Aug 31, 2013 1:23:07 AM CDT
http://www14.software.ibm.com/webapp/wsbroker/redirect?version=pix&product=was-nd-dist&topic=cwim_fedrepos
File name: cwim_fedrepos.html