Business scenario - Federated Directory Server
Federated Directory Server is a hybrid approach that addresses the security and collaboration requirements of directory services in various business scenarios. The following examples are some of the business needs that the features of Federated Directory Server can fulfil:
- You want to enable a central authentication service. However, you might want to leave passwords in place in the original source directory.
- You are required to manage groups across multiple directories to support services like enterprise messaging and access control.
- You want to augment your identity information so that the central LDAP directory can support the specific needs of applications and services.
While Security Directory Server is the centralized core back-end directory server, Federated Directory Server treats it more like a cache of information. Unless you want to do so, you do not have to use IBM Security Directory Server to manage the data. We can choose the level of service that you require.
The specific needs of customers can be categorized into the following scenarios that are illustrated in the diagram.
- Migrate directories or co-exist
-
- We can define the schemas and the amount of information that must be migrated. For example, we can provide more scalability and flexibility to data sources by migrating to Federated Directory Server without having to expand the schemas in the original data source.
- Merge several data sources or directories
-
- When you migrate or merge data from different data sources, the relationships can contain advanced mapping and data transformation. For example, we can integrate users and groups, maintain or flatten directory hierarchies, and create dynamic groups in Federated Directory Server that span data sources.
- Enrich or augment with data from other sources
-
- We can selectively add more data with a particular condition from another data source by setting up a join with the endpoint.
- Selectively write back changes to the original source
-
- If information is modified in the target directory server, it can be written back to the endpoint. However, the write-back selective because some customers might want a barrier to preserve the original data in the endpoint.
- Federate authentication back to the original source
-
- Federated Directory Server can send the authentication request back to the endpoint where the credentials are stored so that the authentication process happens at the endpoint. The credentials are not required to be stored in the Federated Directory Server unless you choose to do so.
For example, we can combine the various capabilities of Federated Directory Server to create a custom solution that is specific to your requirements. Assume that you have an Active Directory that you want to use for single sign-on. You want to provide more scalability to it for more uses like social networking, but do not want to expand the schemas. You can migrate the data selectively, for example, only the email addresses of the users. Federated Directory Server also pulls the distinguished name (DN) from the source directory. We can then use the pass-through authentication capability of Federated Directory Server and retain the password credentials in the source directory itself without pulling it into the target directory. The user can log in to IBM Security Directory Server by using a unique attribute, which is the email address in this case. IBM Security Directory Server does a bind with the DN back to the Active Directory from where the user came. If a successful response is returned, then the user is authenticated.