What is a Federated repository?

Federate repository came in to existence from WAS 6.1 onwards.

1. Federated repositories enable you to use multiple repositories with WebSphere Application
Server.
2. 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.
3. All of the user repositories that are configured under the federated repository functionality are
invisible to WebSphere Application Server.
4. When you use the federated repositories functionality, all of the configured repositories, which
you specify as part of the federated repository configuration, become active.
5. 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.
6. Unlike the local operating system, standalone LDAP registry, or custom registry options, federated
repositories provide user and group management with read and write capabilities.
7. 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.

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.

This table lists federated repositories versus user registry implementations.

Federated repositories User registry

Supports multiple types of repositories such as
file-based, LDAP, database, and custom
However, the federated repositories functionality
does not support local operating system
implementations.
Supports multiple types of registries such as
the local
operating system, a standalone LDAP
registry, and
a standalone custom registry

Fixpack5 With this service release, the federated

repositories functionality supports local operating
system implementations.
Supports multiple repositories in a realm within a Supports one registry only in a realm within a
cell. cell.
Provides read and write capabilities for the Provides read only capability for the registries.
repositories that are defined in the federated
repository configuration.
This does not provide account and password in Provides account and password policy
federated repository. 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

Additional:

What is federated repository?

Before now, the support in IBM WebSphere Application Server for environments where user
information was stored in multiple independent user registries was somewhat limited. Prior to
Version 6.1, the only registry options available were:

Local operating system registry.

A single, standalone Lightweight Directory Access Protocol (LDAP) registry.

A single implementation of the Custom User Registry interface.

It is possible to implement a Custom User Registry that enables access to multiple other registries,
but this can involve a significant development effort that ultimately would only support read-only
operations.

WebSphere Application Server V6.1 provides a new option: a federated user repository. This feature
makes it much simpler to use multiple repositories, since this capability is achieved through
configuration -- rather than development -- with the use of the new Virtual Member Manager
(VMM).

In essence, this feature provides the ability to map entries from multiple individual user repositories
into a single virtual repository. The federated repository consists of a single named realm, which is a
set of independent user repositories. Each repository may be an entire external repository or, in the
case of LDAP, a subtree within that repository. The root of each repository is mapped to something
called a base entry within the federated repository, which is basically a starting point within the
hierarchical namespace of the virtual realm.

What we are discussing here is the idea of one logical registry containing users from multiple
underlying repositories. To the WebSphere Application Server runtime, there is still only one
registry, and thus, all applications in the cell still share this one single registry

A federated repository enables you to use multiple repositories with WebSphere Application Server
V6.1. These repositories, which can be file-based repositories, LDAP repositories, or a sub-tree of an
LDAP repository, are defined and theoretically combined under single realm. All of the user
repositories that are configured under the federated repository functionality are transparent to
WebSphere Application Server.
Tips for multiple user repositories: The user ID and the DN for an LDAP repository must be unique in
multiple user repositories that are configured under the same federated repository configuration. 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.

Have you some firewall blocking ports between DMGR and node?

Check with if you have some connection in SYN_SENT

*nix:
netstat -na|grep SYN_SENT

Windows:
netstat -na|findstr SYN_SENT

Can you check the connectivity between DMGR and node from both sides?

From node host to DMGR:

telnet DMGR_HOST_IP CELL_DISCOVERY_ADDRESS_PORT

From DMGR host to node:

telnet Node_HOST_IP NODE_DISCOVERY_ADDRESS_PORT

Tell us if you need more support.