AppNote: Directory Design for Identity Management Solutions
Novell Cool Solutions: AppNote
By Blair Thomas, Garth Williamson, Jeremy Carter, Stuart Smith
Digg This -
Posted: 21 Apr 2005
Chinese version of this AppNote: http://www.novell.com/coolsolutions/appnote/14533_c.html
Recommendations for directory designs have changed and evolved a great deal over the past several years. Initially, the belief was that each organization should work toward a single directory design to simplify administrative tasks. Administrators worked diligently to design hierarchical trees to help logically place users close to the resources they used. Although this design is very desirable for a file/print directory, it presented challenges as an authentication or LDAP directory. Also, administrators discovered that there were still multiple other directories in use in their environments that required separate administration and security. Often, separate IT groups were staffed to administer the separate and heterogeneous directories and their corresponding identities.
Figure 1 - Heterogeneous directories
Recently, the IT industry has been pushing for a way to simplify the administration of the various directories in an organization and to reduce the costs associated with the administration of the directories and the identities in the directories. Secure Identity Management (SIM) solutions have been introduced as an effective way to simplify directory administration and to securely handle identities within an organization. Key to the successful SIM implementation is a sound directory design. This document introduces principles of SIM directory design and synchronization as a solid foundation for SIM solutions.
SIM Design and the Identity Vault
The starting point for SIM design is the Identity Vault. The identity vault acts as a secure central repository for all identities, including their attributes, roles and relationships.
Figure 2 - Identity Vault
The Identity Vault also serves as a hub to accept and distribute identity information from or to other directories as needed. Directories that send identity data to the vault are information providers. Those directories that receive identity data from the vault are information consumers. Because the identity vault needs to interface with all other directories in the organization, the underlying directory for the identity vault must be secure, reliable, flexible and fast. Novell eDirectory is the perfect directory for the identity vault.
The basic SIM directory synchronization model is as follows:
Figure 3 - SIM Directory synchronization model
In the past, sharing data between the disparate directories and databases and keeping the data current was not an easy proposition.
At this point you may be wondering why there is a need for multiple directories and how multiple directories would fit in at your company, especially because the past recommendation was focused on how a single directory would provide all the functionality needed.
Since we don't live in an ideal world, it is useful to explore why a single directory may not provide a complete identity solution for your organization. Let's look at a short list of some of the limitations of a single directory and how these limitations become a security risk, performance bottleneck, or relate to a myriad of other issues.
Single-Directory Limitations, Requirements, and Challenges
Here are some of the limitations of single directories, arranged by category:
- Internal and External hackers
- Exposure of user identity information
2. Performance issues
- Tuning for specific types of operations
3. Partition size
- Requires more partitions to support LAN/WAN infrastructure
- Administration using hierarchical design
4. Inflexible design
5. Replication and Fault Tolerance
- Replica close to the consumer
- Mesh replication model may not scale
- Contain all user attributes
- Possible exposure of all identity data to all consumers
Below is a partial list of directory requirements:
- Business requirements
- Vendor, Partner and Customer relationships
- Risk Management
- Organization Goals and Model
- Geographic needs
- Legal concerns
Judging by the list above, a single directory may not provide the functionality needed, even with extensive directory planning. And as any IT professional knows, the directory can change with any of the following: acquisitions, mergers, corporate reduction, corporate expansion, new product lines, new/expanded partners and vendors. So the key to any directory is designing it for flexibility - which is much easier said than done.
Now here are the challenges you face with a single directory, keeping in mind the above requirements:
- Trying to provision user identity data from multiple providers
- Having multiple access from internal and external consumers, without knowing their intentions
- Managing security and performance from a single directory
This single directory can be inundated protecting user identity information and providing abundant services such as file and print, etc.
The Multiple-Directory Advantage
Now let's think about how multiple directories change the rules and simplify implementation of an identity management solution. Let's explore the use of a multiple- directories solution in an identity provisioning environment. We are convinced that multiple directories can be leveraged by almost all organizations, regardless of size and the number of objects in the directory. According to the diagram below, there are three design considerations:
- The identity vault
- The identity providers - directory/database
- The identity consumers of the users identity information
Figure 4 - Identity Management model
The identity vault is the key to a concrete user-identity solution. An identity vault should be thought of as a bank vault that only allows access by a few individuals - trusted administrators - with proper access control rights. Here are a few points to help in understanding what an identity vault represents.
- The identity vault could be called a mega directory, a repository, a secure directory, global directory, or meta-tree.
- The identity vault is a hub for the flow of all user identity information from providers of user data to the consumers of that user data.
- The identity vault will hold an aggregation of all identity data/attributes. All other directories should only have a subset of these identity data/attributes.
- The identity vault should never be accessed by users but only by 1) super administrators of the directory and 2) the IDM2 connectors synchronizing user identity data from the providers to the consumers.
- For added security, all user accounts can be disabled in the identity vault and enabled in the other systems by keying on an attribute value. Also, the identity vault can be isolated so only specific IP addresses or segments can access it.
- By using connectors to the identity vault, you enable other directories, databases and domains to be configured to support the services consuming them.
- User identity data can be transformed as it flows to and from the identity vault. With attribute values transformed in this way, you can design schemas to support the needs of the disparate systems.
- It should be a rock-solid access control foundation.
- It is the basis for role-based personalization and rights administration.
When properly designed and implemented, the identity vault can act as a repository for all user identity data, sensitive or non-sensitive. Your organization can limit the user identity data exposed internally or externally. This allows for intense security throughout the company. Once the identity vault has been created using IDM2 connectors (see Identity Manager Drivers and Synchronization below), user identity data can be provisioned in and out of the vault. These connectors will only be allowed access using a security connection such as SSL, at a minimum, which can be increased as required.
A directory provider is an existing or new directory, database, or application that other directories rely on to supply user identity data for their consumption. This identity data is typically transferred between directories manually, which lends itself to data inconsistencies, long wait periods for use access, and security issues. The goal is to do the data entry once and then provision that data to other systems
Data providers or sources could be any of the following:
- HR databases
- Platform Directories
- eMail and message systems
- Other databases
Usually, providers are authoritative sources of some subset of a user's identity information. User identity information can be provided by one source or multiple sources. Together, they make up a user's identity that is synchronized to the identity vault.
By using connectors, the flow of individual user attributes from the source is controlled to the identity vault and back to the provider as needed. This control would represent the organization business strategies and requirements. Data providers may also be data consumers of a subset of the user's data from the Identity Vault.
By using IDM2 connectors, the provider structure and schema will typically require no change. If change is needed, it would be dictated by business requirements. As mentioned before, the goal is to enter data once, then have all IDM2 connected systems be updated with the information needed by that system. By using this model, the total cost of ownership (TCO) is reduced and data accuracy is greatly enhanced.
Consumers and Service Directories
The service directory is a directory, database or application designed for a specific purpose or role in the organization. For example, a platform directory/domain (file and print directory) is considered a service directory. Because the schema and structure will usually differ from the identity vault, the service directory can be designed to match the needs of the consumers of the data. Only the user identity data that is required by the consumers of that data is provided to the service directory - and nothing more. User identity data should never be compromised as it has in the past with a single directory.
Here are a few of the advantages of service directories:
- They limit user data exposure.
- Authentication rules, policies, security, consumer requirements can be tailored to the needs of what the service directory is providing. For example, an authentication directory would require attributes that a white page directory wouldn't.
- The service directory schema (see Schema) can be designed to match the need of the services consuming the data, so it could be different from the identity vault or any other directory in the identity solution.
- The Service directory design will meet the consumer needs.
- The Service directory can residue in the DMZ without ever jeopardizing user identity information.
And here are some of the characteristics of service directories:
- They are tuned for a specific service level requirement (SLR), defined by the application, the business requirements, the organization, or the consumer of the data. They protect the identity vault from unwanted access.
- The general-purpose directory is tuned for general purposes, such as Read/Write operations, general indexes. A directory used for LDAP access would be tuned for reads and specific indexing.
- They can be viewed as a specialty directory to a limited amount of user information for authentication, white pages etc.
With a service directory in place that fills a specific role or group of roles, the IT staff can design and secure it more easily than if the directory does multiple roles that may not relate, or may have internal and external access. For example, a service directory could reside in the DMZ for web access for customers. The service directory data would be synchronized from the identity vault or repository by a IDM2 connector. Because the identity vault is the hub for the user identity data, the connector guarantees that only the required user' attributes are synchronized to the directory. Provisioning only a subset of the user's identity information reduces security risks and the likelihood of the user's identity being exposed.
A few years ago, creating this flow of data was almost impossible. That changed when directories, HR systems and databases were able to use common protocols such as LDAP, XML, etc. These protocols now allow vendors to share identity data, reducing TCO for the company that implements them.
The schema makes up the directory object identity. By default, eDirectory offers a fully functional base schema that defines a wide variety of objects and their attributes. If the base schema does not fit the company's requirements, there are many options available to the IT staff to extend the schema to meet those needs. For example, consider the use of user objects. A company may have multiple types of users, such as employees, contractors, and vendors. Each of these user objects require specific attributes that make up the identity of that user type. Extending the schema allows an employee user to have different attributes or identity than a vendor user or a contractor user.
There are different ways a company can uniquely identify objects in a directory. Below is a table of four schema options, each of which could be combined to accomplish the end results. Advantages and disadvantages of each option are also described.
|Use the Base Schema||1. Simplicity
2. Uses existing unused attributes to help uniquely identify a class
3. Uses existing attributes as a temporary attribute for IDM2; unused attributes can store permanent values for objects
|1. Schema may not meet company's requirements
2. Attribute names don't match or represent the actual attributes being used
3. Novell or 3rd-party software vendor may already use the attribute
4. Very inflexible
|Extend the base schema||1. Create attributes that match company requirements
2. Easy to create
2. Effective classes are not easily deleted once created
3. Attributes added to base classes are not easily deleted
4. Extending base classes like Server, User, Organization, is permanent
5. Can lead to schema bloat
6. Does not address default ACL rules for User object class
7. Does not change containment rules for existing classes
|Use Auxiliary Classes and attributes to the base schema||1. Allows an auxiliary class to more uniquely represent different classes of users for example or different groups of objects
2. Straightforward deletion - to remove Auxiliary classes and the extended attributes used by that class, all objects using that attribute must have a null value
3. Flexible and dynamic
4. Auxiliary classes are groupings of attributes that can be attached to existing objects
5. New attributes and classes can be easily deleted from the entire tree or specific users
6. Objects can belong to multiple Auxiliary classes
7. An object is the sum of all the effective attributes and the attributes inherited from its auxiliary classes
|1. Not available to older versions of eDirectory, prior to NDS8
2. Not the best choice if every object of a specific type needs the attribute
|Custom Schema||1. Define all classes and attributes to match company needs. Will not use eDirectory base schema. For example: user base class will not be used.
2. Classes can be made to inherit per company requirements, not Novell's
|1. eDirectory management will be custom or LDAP
2. Referential integrity is not maintained by eDirectory, requiring administrator to ensure it
3. eDirectory utilities will not repair a custom schema
4. Not easily supported
5. Still must use base schema for server objects etc
Using one or a combination of the above options, a company can develop a schema that will easily support their business requirements. The key to a successful schema strategy is to have a schema that represents needs of the company, represents the objects stored in the directory, and can be changed as the business changes. Remember that eDirectory plays a crucial role in defining how the IDM2 drivers synchronize their information between systems.
Acting upon the attributes of each user/object, the drivers use the attributes as data elements that govern the decisions or business rules and logic in the overall solution.
Identity Manager Drivers and Synchronization
We have discussed directories and the schema that help with the object identities, but this does little good unless this user identity information can be shared company-wide. Identity Manager 2 (IDM2) is the application that enables sharing of user information to all systems in a company, and externally if the business requires it. In IDM2 there are drivers or connectors that are used as a connecting framework for the directory-enabled solution. These drivers enable synchronization of user data and passwords to other heterogeneous systems in the network. Identity synchronization and provisioning together form the process by which you manage the various instances of an individual user's identity, wherever it resides across all systems.
Figure 5 - Identity Synchronization
The Identity Manager Drivers act as the connector between eDirectory and other disparate systems within the network. When data in an application is changed, the data is sent to the DirXML engine and then stored in the Identity Vault. This data can be used by the other connected systems as needed. This dynamic sharing of information allows a much more accurate data store to exist in the enterprise network, as data can be entered once and synchronized to other systems.
The next step is to link the individual pieces of an Identity Solution all together into an overall solution. Here's a simple example of an identity solution.
XYZ Corp has identified several challenges to automating its current Identity Management solution. Among these challenges are the following:
- Reducing administrative costs associated with identity management
- Reducing the amount of time required to obtain computer accounts
- Providing employees and contractors secure internal access to multiple systems
- Automating the creation, deletion, and disabling of employee accounts in HR System and Active Directory/ Exchange 2000
- Reducing administrative costs by automating identity and account management processes
Using these requirements, let's proceed on providing a solution. Three decisions need to be addressed:
- Schema requirements
- Identity Vault design
- IDM2 drivers
XYZ Corp has decided the schema will be extended with the auxiliary class "XYZUsers", which will use the following attributes:
- XYZorgUnit - used for user placement and group creation in the XYZ Domain
- XYZaction - used from HR to Identity Vault to determine if a user object will be created in the XYZ Domain
A new directory tree is needed for this solution to act as the Identity Vault. The Identity Vault trees are typically a flat-tree design. The XYZ Identity Vault will be designed with 3 partitions: root, Users, and Services. Root will be only a few objects and is designed to be static. All user objects will be placed in the User container, and the Services container will hold the server-related objects, IDM2 objects, etc. Also, two IDM2 drivers are required for this implementation: an HR driver and an AD/Exchange driver.
The Identity Management solution for XYZ Corp is shown in the diagram below:
Figure 6 - Sample Identity Management Solution
The HR driver will synchronize all employees in the HR database to the XYZ Identity Vault, with the following conditions:
- The placement in the Identity Vault will be determined on the XYZaction value:
if XYZaction=Y, the user object will be placed in the o=Users,ou=Active container
If the the XYZaction=N, the user object will be placed in the o=Users,ou=Disabled container in the User container.
- All user accounts in the Identity Vault will have their login disabled = true.
- User accounts will never be deleted in the Identity Vault; they will only be moved between the Active and Disable containers.
The AD/Exchange Drivers will synchronize with the following conditions:
- The user will not be synchronized to the XYZ Domain unless the XYZaction=Y.
- If the XYZaction=Y, the user will be placed in a container using the value from the XYZorgUnit attribute. If the XYZorgUnit container structure does not exist, it will be created. A group object will be created using the XYZorgUnit value, then the user object will be created and added to the group.
- User group membership will be accumulated and never removed by the AD Driver. For example, when the user is moved to a new container due to a change in the XYZorgUnit value in the HR system, the user is added to the new group membership but not removed from the previous one.
- A user created in the XYZ Domain will get an e-mail address that will synchronize back to the Identity Vault, then to the HR system.
- If the user exists in the XYZ Domain, and if the XYZaction attribute changes its value from "Y" to "N", the user object will be disabled and moved to the o=XYZUsers,ou=Disabled container. All group memberships will be removed from the user object when moved to the Disabled container.
- If the user exists in the XYZ Domain, and if the XYZaction attribute changes value from "N" to "Y", the user object will be enabled and moved from the o=XYZUsers,ou=Disabled container. It will be placed in a container using the value from the user's XYZorgUnit attribute. If the XYZorgUnit container structure does not exist, it will be created, and the user object will be created there. The user will be added to all the groups associated to the container the user is being added to.
- User accounts will not be deleted from the XYZ Domain by IDM2.
From this simple example, the Identity Vault was created and populated from the existing HR system. The schema was extended in the Identity Vault to allow logic to determine the placement of the user objects and whether the user account is created in the AD Domain. Group objects were created and populated using attributes. This example demonstrates the power of IDM2 and the value of the use of an Identity Vault, and how the schema can be used as future needs arise or for new business requirements.
Novell Cool Solutions (corporate web communities) are produced by WebWise Solutions. www.webwiseone.com