I’ve been thinking recently about what the best method is for creating an authoritative Identity Store for use in a provisioning solution.
it seems to me that there are three ways to do this:
- Use authoritative attributes from one or more trusted repositories to create a master authoritative store.
- Read each repository into a separate database table and merge them together into a temporary or holding table.
- Read each repository into a single holding table, overlaying information as needed.
I think all three methods are viable, but one main question needs to be asked first:
Does it make sense from an architectural or process standpoint to have a holding table. There are times wherer the holding table can be used for other purposes (basis for a Virtual Directory, feed for an external access application and just plain redundancy. The issue however is that these tables take up two critical resources, time and storage. Building holding tables requires extra operations (passes in the SAP NetWeaver identity Manager world) and in large organizations these table(s) can get large fairly quickly.
The other issue with building a holding table from multple tables is that there must be a common key between all of the tables. Strangely enough this is not as common as one would think, especially when some of the tables that will make up the authoritative store are from legacy systems.
Whenever possible, I prefer to use authoritative attributes as it helps to cut down on speed and storage. As I was saying to a colleague the other day, it’s a simply that execution time is a function of the number of repositories to be processed and the number of attributes in the repository. The more attributes in the repositories, the longer it takes, and vice versa. This method also reduces storage space and elimiates the need for links between the repositores.
The next questions becomes, what do we do with the old sources one you have a solid authoritative store, but that’s for a future article.