IDM Best practices: The Tree

IDM Best practices: The tree structure of an identity vault

Being consultants, normally, when we start to design an IDM solution, we advise our customers on tree structures, naming conventions, object placements etc. But we only advise them! We do not tell them how to do it. If a customer want to have a different setup or naming convention, fine with us. We do not want to be mixed up in the big discussion that might arise. Let the customer decide!

From an IDM perspective this attitude will only result in more or less work in building transitions. And that should be the main focus as an consultant, et the customer know how many extra transitions will need to be programmed and tell them the impact on the maintanance.
There are however a few design issues in every design that you do want to discuss. These are the issues that will make live as a programmer more easy and from which the customer will benefit a lot. One of them is the global structure of an Identity Vault tree.

Antoher is the use of "support" drivers with added functionality, i'll cover that in another article.
When i teach the IDM ATT's i'll always start a discussion on this, it ends up with a lot of ideas. My idea was to write an article on this because everybody deals with this.

The article is online here at Novell Cool Solutions

Let's look at the basics, What are the goals for the identity Vault tree :
1) It should be fast.
2) It should contain any information on entities as is needed.
3) It should be scalable.
And of course many more!

For 99% the Identity Vault is a flat tree, there are containers for all active users, devices, groups organizational objects etc, and last but not least inactive objects. (we want to maintain them for a short or longer period)
These object will be spreaded over different containers for perfomance reasons in most enteprise environments.

The discussion i want to start in this article handles the placement of active and inactive objects because we see some customers getting into problems with this.
Again : For a number of reasons most companies leave their inactive users within the IV and delete them only after a certain amount of time.
But, at the same time there are two important features for this inactive users.
1) They are not supposed to show up in address books etc.
2) They must not be able to login.

So, the following picture (remember DS Designer) is from a typical Identity Vault tree structure (even in the IDM ATT's)

The client for a Identity Vault systems are mostly LDAP clients, so think LDAP for a minute!
Let's review this from an LDAP perspective, because we use this perspective a lot in authentication, authorization and directory searches etc, and even part of the User Application

A nice issue arises when using this design:
1) What would the baseDN be when selecting active users? Normaly you would say cn=Active,ou=Users,o=Vault.
But... Most LDAP clients use one baseDN for all queries, so with this baseDN we miss out on the active groups and others. Even if you're not using these info right now, it might be used in the future for authorization purpose.
So let's change the the baseDN to o=Vault.
But... In this case i would also see the inactive users in a yellow page application!!

Another issue
If yo set the baseDN to o=Vault the inactive users might even be able to login. Of course we can set Login disabled, but that is an extra action to take.
And there are more.

Conclusion. With a design like this you might end up doing a lot of coding to make sure that the system will act as desired.

So using a different approach on the tree structure might prevent a lot of work.

First a important note! We have a saying in the Netherlands : "There are several roads leading to Rome" (which is in Italy ;-) ). So what i propose is only one way to do it,it is not the law and there are several pro's and con's.

This is the structure most commonly used by our consultants.
The design is based on some important principles :
1) A logical separation between fields of functionality.
2) An active link between user objects and his/her ralation to the company (One User = One Entity with One or more roles in One or more departments.)

This priciples will result in a tree design with one container with all active items (Users, Groups, devices, SAP object (if any)).
Another container as a placeholder for objects that regard IDM issues (inactive users, workorders if any)
And one or more container for Servers, services (Driver-set) and tree administration.
Note! For all kinds of reasons, it is mostly not a wise idea to use several Organizations.

So these principles will result in a tree design like the following :

Again, there are several way to reach your goals.

There are some other big advantages with this design.
1) The only rules that need to be build is something like : Delete, disable or veto account when moved to inactive.
2) The baseDN can be set on ou=resources,o=corp and only active entities will be found for authentication, authorization or directory queries.

Most important, of course, is to think ahead. What will the future be for our Identity Management system. If you thuoght that over in the design, you're half way there.

Main Menu