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 wants 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. Let the customer know how many extra transitions will need to be programmed and tell them the impact on the maintenance.
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.
Another 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.
Let’s look at the basics, What are the goals for the identity Vault tree:
- It should be fast.
- It should contain any information on entities as is needed.
- 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 objects will be spread over different containers for performance reasons in most enterprise 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.
- They are not supposed to show up in address books etc.
- 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:
- What would the baseDN be when selecting active users? Normally 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 baseDN to o=Vault.
But… In this case I would also see the inactive users in a yellow page application!!
If you 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.
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.
This is the structure most commonly used by our consultants.
The design is based on some important principles:
- A logical separation between fields of functionality.
- An active link between user objects and his/her relation to the company (One User = One Entity with One or more roles in One or more departments.)
This participles 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.
So these principles could result in a tree design like the following :
Again, there are several way to reach your goals.
There are some other big advantages with parts of this design.
- The only rules that need to be build is something like : Delete, disable or veto account when moved to inactive.
- The baseDN can be set on ou=resources,o=corp and only active entities will be found for authentication, authorization or directory queries.
Main focus is that you got a better separation on different types of object to prevent interference
Most important, of course, is to think ahead. What will the future be for our Identity Management system. If you thought that over in the design, you’re half way there.