Novell Home

Data Sharing With IDM2 In The Real World

Novell Cool Solutions: Feature
By Kevin Burnett

Digg This - Slashdot This

Posted: 22 Dec 2004
 

The objective of this article is two fold. One, to introduce the reader to Novell's advanced security and synchronization system called Identity Manager 2 and two, to describe a real world scenario where Identity Manager 2 can act as the central data-sharing mechanism. In this article we will actually go through the steps of assessing and then implementing Identity Manager 2 as the heart of a true heterogeneous network.

Table of Contents:

Overview of Identity Manger 2
Real World Analysis
Yale University
Problem at Hand
Proposed Solution
Requirements Assessment
Reinventing eDirectory Implementation
Center of Synchronization
Design Phase
Platforms
Applications
Challenges
Write Drivers
Policies
XML
Scripts
Testing
Simulation of Existing Network
Safety Net of Testing
Working Out the Problems
Production Implementation
Process
Checks and Balances
Verification of Operation
Conclusion
Wrap it all Up

Overview of Identity Manager 2

Identity Manager is Novell's marketing name for what was invented as DirXML. The name DirXML comes from the directory and XML, which allows for a slick way of changing data from one form to another efficiently. Nsure Identity Manager 2 provides a secure way of moving directory information from one platform to another, for example eDirectory to Active Directory, and back if need be. Passwords can be synchronized, as well as user attributes, group attributes, or custom objects. As Novell's Marketing Team will tell you, with these capabilities you will realize tangible business benefits: streamlined administration, increased security, reduced costs and a swift return on investment. Let's highlight some of the features and benefits of Nsure Identity Manager 2.

Nsure Identity Manager 2 offers you the following capabilities:

  • User provisioning
  • Password management
  • User self-service
  • Point and click customization
  • Role-based administration
  • System-wide auditing and reporting
  • Corporate address book via eGuide

Some of the benefits of incorporating Nsure Identity Manager 2 are:

  • Increased operational efficiency
  • Support compliance with industry regulations
  • Reduce administration and help desk costs
  • Reduce security risks
  • Empower users
  • Build productive business relationships

New Spiffy Interface

The big change, or most noticeable change for Nsure Identity Manager 2 is the interface. Prior versions of DirXML required the use of ConsoleOne snapins, which worked OK, but nothing like the ease and simplicity of the Web-based interface in Nsure Identity Manager 2.

Note: For specifics on installing, setting up and configuring Nsure Identity Manager 2 drivers, see the documentation provided on the Novell documentation web page: http://www.novell.com/documentation/.

After installing one or more drivers, you will bring up and see a screen like the following:



Figure 1 -- Nsure Identity Manager 2 Driver Set Screen

Each driver you have installed in a given driver set will appear in a screen like this. Clicking on a driver, such as the one noted with a "1" will take you to the following screen:


Figure 2 -- Nsure Identity Manager Driver Overview Screen

Looking at Figure 2, the top arrow, going from the driver (application) to eDirectory is the Publisher. This channel typically carries data from an application (Active Directory, Oracle, LDAP, etc.) to eDirectory. The arrow going from eDirectory to the driver (application) is the Subscriber channel. This channel carries data from eDirectory to your disperse application.

Looking closer at Figure 2, you will note little arrows on both the Subscriber and Publisher channels. These are locations you can place policies, rules or style sheets. Looking at the Publisher channel, the arrows are as follows (from application to eDirectory):

  • Input Transformation
  • Schema Mapping Policies
  • Event Transformation Policies
  • Driver Filter
  • Matching Policies
  • Creation Policies
  • Placement Policies
  • Command Transformation Policies

For the Subscriber channel we have:

  • Driver Filter
  • Event Transformation Policies
  • Matching Policies
  • Creation Policies
  • Placement Policies
  • Command Transformation Policies
  • Schema Mapping Policies
  • Output Transformation

Let's look at each of these in a little more detail.

Input Transformation
This policy or style sheet can perform two main functions; implement data specific business rules and translate XML to XDS if need be. The type of policies or style sheets used here take care of any conversions needed between the application and eDirectory. This policy is only on the Publisher Channel.

Schema Mapping Policies
This policy holds correlations between attributes of eDirectory and the destination application. This allows data to be passed from the application to eDirectory and back again, unless the driver filter filters out the attribute or object.

Event Transformation Policies
Used on both the Subscriber and Publisher channels to convert from one event to another. For example, eDirectory may send a create instruction to the destination application, which only allows modifies. This rule could be used to convert the create to a modify.

Driver Filter
The driver filter gives you the flexibility to determine which object and attributes of those objects are sent to either eDirectory (Publisher Channel) or the application (Subscriber Channel). This gives you a lot of flexibility since you can only pass the objects and attributes needed, thereby reducing traffic over the network.

Matching Policies
This policy, along with the following two are only implemented during an Add event. The matching policy allows you to guarantee uniqueness of an object in the destination data store. They specify the criteria used to attempt to match existing objects in the destination system. The criteria you can use for these matches include the following:

  • Path information
  • Class name
  • Attribute names

  • If the matching mechanism can't match the object to an existing object using your criteria, it allows the command to continue through the next policy.

    Creation Policies
    This is the second policy that is only invoked for Add events. Create policies specify what information the driver must have in order to create an object in the destination name space. For example, you may want all user objects to come from a specified container or containing specific attributes.

    Placement Policies
    Placement policies are the third and final type of policy that is only invoked for Add events. Placement policies determine where the new objects are placed in the database. Really, a Placement policy is only required on the Publisher channel, but you can also have one on the Subscriber channel if needed.

    Command Transformation Policies
    These policies, available on both Subscriber and Publisher Channels, allows for the transformation of commands between eDirectory and the application and vice-versa. An example would include updating a user's Universal password from eDirectory to the application or setting the value of an attribute.

    Output Transformation Policies
    Only used on the Subscriber Channel. Used for changing information sent from eDirectory into a format acceptable by the application. For example, transforming eDirectory's naming nomenclature to that of Active Directory's naming nomenclature.

    Nsure Identity Manager Policies
    New with Nsure Identity Manager 2 are policies which are quite easy to create. For the most part, you don't need to struggle with the XML/XSLT/XPATH, etc. style sheets that you previously had to. Granted, you will still need to write style sheets to do very specific items, but the wealth of options offered by the new policy builder does make like a lot easier. Figure 3, below, shows the policy builder.


    Figure 3 -- Nsure Identity Manager 2 Policy Builder.

    The Nsure Identity Manager 2 Policy Builder is a web-based interface that allows quite a lot of flexibility in defining rules across all of the possible policies mentioned above. You have the ability to select from a wealth of conditions and actions. For example, you could implement a matching policy by saying the following:

    If class name equal case insensitive user

    Do find matching object CN.

    This would check all new add commands against the user objects in the destination data store, checking for matches using CN. If a match was found, the add event would be terminated.

    Real World Analysis

    Novell has Nsure Identity Manager 2 installed at several of the biggest companies, largest Universities, and Governments in the world. One of these is Yale University. The remainder of this article is going to loosely follow an installation at Yale University. It will discuss how to asses the need for Nsure Identity Manager 2, design a solution using Nsure Identity Manager 2, test the configuration and lastly take the solution to the production network.

    Problem At Hand

    Yale University, not unlike a typical university, had several NetWare servers, Mini-Computer based serves and main frame computers. The main focus of Yale's IT department was to make administering a very diverse network easier. Novell's Nsure Identity Manager 2 was chosen to accomplish this goal. The main two reasons being ease of administration and the ability to connect diverse systems and directories together.

    Proposed Solution

    Typically when you want to introduce a large-scale Nsure Identity Manager 2 into a networked environment, you will create a central server called an Identity Vault or Workforce server. This server will not be used to create or administer users, but rather to act as a hub for all of the Nsure Identity Manager 2 driver connections. By doing this, you can reduce the amount of traffic on your network, but better yet, organize your network and make maintenance easier. Take a look at Figure 4, below.


    Figure -- 4 Extensive Nsure Identity Manager Implementation Design

    Typically what a consultant will do when going on-site to solve a problem like this can be composed of several steps:

    • Requirements Assessment
    • Design Phase
    • Write Drivers
    • Testing Phase
    • Production Phase

    Let's look at each of these phases of implementation in greater detail starting with the next section.

    Requirements Assessment

    This is the most important step of the five listed above. If mistakes are made during this phase of the project, they will ripple down throughout the rest of the project.

    A consultant will go on-site to a company and spend the necessary time meeting with company technical, marketing and other people to get the necessary information to formulate a plan. There are three stages to this information gathering procedure:

    • Meet with necessary people to find out what their requirements are.
    • Create a Requirements Assessment Document (RA) that describes the needs.
    • Meet with necessary people to make sure the RA is accurate!

    In our Yale example, several things will need to happen with this discovery part of the project. You need to find out what the current network configuration is like. You then need to find out what the company wants to have happen to the network. How do they want the data connected between systems. What rules do they want to implement between directories, trees and servers. Is hardware a limitation? Hold meetings with as many groups of people as you need to to get the information you need. If some of the directories are off-site, meet with those people off-site to make sure you get their requirements. Over time, a plan will form from which a diagram like Figure 4 will be the result.

    Armed with the information gathered in this part of the project, you are ready to move on to the design phase.

    Design Phase

    The most important part of this phase is the creation and verification of the RA. This is a make it or break it part of the project. Armed with the information from the previous section of this article, you are ready to write the RA. You should have the customer's current network diagramed and also what you want the new and improved network to look like (Figure 4). If you happen to have an existing network with a DirXML implementation, you may want to take into consideration "old" and "new" directories to make switching over to the new implementation easier.

    Referring to Figure 4, note that Location 3 and Location 4 have "old" or existing DirXML implementations. Also note that Locations 1 and 2 are new and did not exist in the previous implementation.

    Once you have your design information and old and new diagrams, you can start writing the RA. When putting the RA together, you want to look at each Identity Manager 2 driver and document it individually. For example, let's look at the Main Org Tree connecting to the Work Force tree using an eDiectory driver pair. The section for this driver would look like the following:

    Note: The text for the next part of this article will be red within the RA proper.

    Main Org eDirectory Driver Specifications

    Overview

    This driver will connect the users in the Work Force tree to the Main Org Tree. The eDirectory DirXML driver actually consists of two DirXML drivers: one in the Workforce tree and one in the Main Org tree. The subscriber channel of each driver communicates with the publisher channel of the other driver. This section will outline the specifications of the Workforce/Main Org synchronization as a whole as if it were a single driver.

    Current Issues

    Issues related to this specific driver are below.

    • None known at this time.

    This is the overview part of the RA document for the Work Force to MAIN ORG Tree eDirectory driver.

    Data Flow

    The following picture depicts the data flow between the Workforce tree and the MAIN ORG tree. The data flow in this driver will be bi-directional.

    This part illustrates the data flow between the trees we are documenting. Also indicates if the driver will have bi-directional data flow or not.

    Mappings

    The schemas for the user attributes being synchronized will be identical so there is no need for object and attribute mappings. The following table specifies the attributes that will flow between the Workforce and MAIN ORG trees.

    MAIN ORG ? Workforce tree attribute mapping for class User

    Transformations

    Transformations are Identity Manager policies that capture events coming from either tree. No transformations will be required to change events as indicated in the Publisher and Subscriber sections of this document.

    Data Transformations

    Data transformations are used to change the format of data into another format. The following data transformations are necessary for this driver:

    • None

    Password Synchronization

    Password synchronization for Identity Manager 2.0 will be implemented for this driver. Password policies and universal password will be implemented in the Workforce tree. The policy and passwords will be consumed by this driver.

    Password Synchronization may include Universal Password or NDS Password or both.

    Events

    This section of the driver RA is the meat of the equation. This section and the following section detail what the driver will do and how it will do it.

    MAIN ORG to WORKFORCE Channel

    The following section describes both the typical behavior of an action type, the requirements, and what transformations to the default driver behavior must take place. The purpose of this publisher channel is process events handed to it by the MAIN ORG tree and send them to the Workforce tree.

    Add Object

    Adds of users coming from MAIN ORG will be allowed.

    Matching Rule

    The CN in MAIN ORG and the CN in the Workforce tree are used to determine if there is an existing user that matches the current user being added. If one user match is found on this user then the add event will become a modify event. If no user matches are found on this user then the event will continue as an add event.

    Create Criteria

    If the following attributes are missing from the add event then the event will be vetoed and the new user will not be created in the Workforce tree:

    • CN
    • Surname

    Placement criteria

    Users will be placed in the USERS container.

    Naming criteria

    The newly created user in the Workforce tree will be named with the MAIN ORG tree naming attribute, which will be CN.

    Initial Password

    The initial password on the new user object will be the MAIN ORG user password.

    Modify Object

    Modifies of users coming from MAIN ORG will be allowed and the data will flow through to the Workforce tree as is.

    Delete Object

    A delete of a user in MAIN ORG will result in a delete of the associated the Workforce tree user.

    Move Object

    Moves will be allowed to flow through.

    Rename Object

    A rename of a user in MAIN ORG will rename the Workforce tree's associated user to the same name.

    Sync Event

    Sync events will be allowed to flow through on this driver.

    WORKFORCE to MAIN ORG Channel

    The following section describes both the typical behavior of an action type, the requirements, and what transformations to the default driver behavior must take place. The purpose of this subscriber channel is to process events in the Workforce tree and send them to the MAIN ORG tree.

    Add Object

    Adds of users coming from the Workforce tree will be allowed.

    Matching Rule

    The CN in the Workforce tree and the CN in MAIN ORG are used to determine if there is an existing user that matches the current user being added. If one user match is found on this user then the add event will become a modify event. If no user matches are found on this user then the event will continue as an add event.

    Create Criteria

    If the following attributes are missing from the add event then the event will be vetoed and the new user will not be created in MAIN ORG:

    • CN
    • Surname

    Placement criteria

    • If YNHHS-SourceDomain is ?Location 1' then the User will be placed in the YNHHOSP.YNH_HSC container.
    • If YNHHS-SourceDomain is ?Location 2' then the User will be placed in the GRNHOSP.YNH_HSC container.
    • If YNHHS-SourceDomain is ?Location 3' then the User will be placed in the BPTHOSP.YNH_HSC container.
    • If YNHHS-SourceDomain is ?Location 4' then the User will be placed in the BPTHOSP.YNH_HSC container.

    Naming criteria

    The newly created user in MAIN ORG will be named with the Workforce tree naming attribute, which will be CN.

    Modify Object

    Modifies of users coming from the Workforce tree will be allowed and the data will flow through to MAIN ORG as is.

    Delete Object

    A delete of a user in the Workforce tree will result in a delete of the associated MAIN ORG user.

    Move Object

    Move events coming from the Workforce tree will be ignored by this driver.

    Rename Object

    A rename of a user in the Workforce tree will rename the MAIN ORG associated user to the same name.

    Sync Event

    Sync events will be allowed to flow through on this driver.

    Once you have the RA completed for the project, you normally have enough information to configure and code the drivers. You can use the RA as a map to make the drivers a reality.

    Write Drivers

    With the RA completed, you are ready to write the drivers. You now know which Nsure Identity Manager 2 drivers you will need for your project, you have the information to write the drivers, and you have a picture of what the final network configuration will look like.

    You will want to write the drivers using the new Policies in Nsure Identity Manager 2 if possible, since it is almost simplistic to do the rules that way. If you do need to implement functionality that the Nsure Identity Manager 2 Policy Builder does not include, you will need to fall back to XML, but that will be on rare occasions. (Nsure Identity Manager 2 does support XML as easily as DirXML did before it.)

    Novell provides documentation for all of the possibilities in Nsure Identity Manager 2 Policy Builder. This is located at http://www.novell.com/documentation/dirxml20/index.html.

    Novell provides quite a selection of pre-built Nsure Identity Manager 2 drivers. Novell is adding new drivers all the time. However, if you need a custom driver to implement you solution, you can either write it yourself using Novell's SDK, at: http://developer.novell.com/ndk/ or you can contract with Novell Consulting to write the driver for you. See: http://www.novell.com/consulting/expertise/securityandidentity.html if you are interested in this option.

    Testing

    Second to creating the RA is testing the drivers you have written in a situation that is as similar to the actual production environment as possible. There are two testing methologies that you should use. Unit Testing and Integration Testing.

    Unit Testing

    Unit testing is the testing of the individual drivers. If you have an eDirectory driver linked between MAIN ORG tree and Work Force Tree, as in our example, you would test the functionality of this driver set only. You would check all of the rules and policies you have written for this driver. You would also create users, etc, and run them through the driver.

    Integration Testing

    After you have tested all the drivers in your implementation individually, you absolutely need to do an integration test, that is, set up all the drivers you have written in a test network that is as close to the real network as possible. It is amazing the problems you will find during this kind of testing. Even if you have unit tested all of your drivers, fixed all the problems you have found, and determined that all the drivers work as specified, put them all together like they will be in production.

    Run a battery of tests that simulate what the customer will be doing in real life. Create users, attributes, groups, etc. and see how it flows through the network. Create a spreadsheet to keep track of your tests and the results. Some of the most challenging problems to fix with the drivers will be discovered in this part of the testing.

    Lastly, fix the problems you discover as you find them. Reason being is that one problem could be causing a string of problems down the tree. Fixing one problem may make several other problems go away during Integration Testing.

    Production Implementation

    When you are happy with the way testing has gone during the Integration part (it is a lot easier to get positive results with unit testing), you are ready to implement the solution on the company's production network. Typically the customer will want to do this over a weekend, or in several phases overnight. Be careful when adding new servers, decommissioning old serves, adding or removing directory trees, etc.

    Run some sort of directory health check before installation (Novell has some TIDs on their Technical Support Website to aid in doing this.). Ensure that all the minimum requirements for Nsure Identity Manager 2 are met.

    Pay close attention to password issues, especially if you are implementing Universal Password in the configuration.

    Once you have the completed the installation, run your Integration test suite to make sure everything functions as expected. Look for anomalies. It is amazing what can sometimes happen when going to production, even after thorough testing is done!

    Conclusion

    Whether you are implementing a non-complex one driver installation or a ten driver installation discussed in this article, the principles discussed herein are valid. Use caution when going to production. Make sure you cover all of your bases in all of the steps before production. Test and test some more. Check for patches, from Novell, for the drivers and IDM2 engine. Also, and I can't stress this enough, make sure you spend ample time in gathering information from the customer. It will make you life a whole lot easier during the rest of the project.


    Novell Cool Solutions (corporate web communities) are produced by WebWise Solutions. www.webwiseone.com

    © 2014 Novell