In the Workshop (pt. 2) – Building an Identity Management Solution

When last in the workshop to build our own identity management system we laid the groundwork for a solution by identifying and analyzing our organization’s sourcing, staffing and human resources systems.  Now that we know where our subjects originate and what attributes are available for them, we next need to determine where identities are used for access and/or monitoring.

Many organizations use one or more directories for provisioning, authentication or access control and bloody wars have been fought over which directory is superior.  Our approach will retain Swiss-like neutrality and can be used with any directory or if there is no directory at all.  While vendor solutions only manage an already-created identity, we are proposing to not only bind the user to an identity, but to create one for them.  With a fully flexible, open standards approach, the consumers of our identity data can depend on us merely for the identity token itself – a dataless key that can be consumed easily by a variety of systems and which, for reporting purposes, can be linked to some controlled and managed set of attributes about the user.

The major challenge we have is selling the consuming processes and systems on using our identifier.  From a security or compliance perspective, we may be able, by policy fiat, to require the universal identifier.  Having that backing was critical to the success of the global identification program I managed at a previous employer.  If we cannot get all identity consumers to use the identifier, start with a few.  Even manual processes like distributing assets such as desk space can benefit from having a single identifier, both to determine the fully-loaded cost of an associate and to increase the likelihood we can collect all company assets when a user terminates.

The last step before we begin building our identity management solution is to answer a few key questions:

Who will build and support the service?

Having a dedicated IT resource that has the skills necessary to craft and support web services is ideal.  If not, we need a project plan that follows the organization’s standard systems lifecycle delivery, change management, and operational support processes.

How do you let the organization know about our service?

Some organizations, particularly those with heavy reliance on web services might already have UDDI (Universal Description, Discovery, and Integration) or similar directory, listing and describing available web services.  More likely, we will have to take our policy mandate (see above), if we were fortunate enough to get it, or our powers of persuasion otherwise and start making the case to key systems.  We can always use the compliance stick.  Once a system owner sees how resource-intensive it is to manually validate active user accounts, they may be more amenable to using a universal identifier.  Even a vendor-supplied system that cannot change its user id may be able maintain an identifier attribute that can be mapped to the user id for reporting and monitoring purposes.

What dataless key do we use?

It does not much matter, but it should be a meaningless value.  The number of characters in the key should allow sufficient capacity for future organizational needs.  In my past experience, we used a lower-case “a” followed by six digits.  Since we assigned an identifier to every contractor and to anyone who had a background check conducted, we were burning through more than 50,000 values per year the first few years.  However, since the identifiers were permanent, that is, if you were assigned one as a job candidate but never hired and then joined the company years later, you retained your original identifier.  So the rate at which ids were consumed would likely slow over time.

An id was never reused.  If we ran out of “a” ids, we would then use “b” as a prefix.  This dataless approach superseded one that had used a department prefix, which proved very cumbersome to manage as the organization evolved and associates moved.  Old ids were converted to the new id scheme by whacking off the first few characters and using an available range of new ids.  There was no difference in how the identifier was assigned to employees or contractors, domestic or international, full-time or part-time.  Most organizations are far too dynamic to attempt to use the identifier for any kind of status tracking.

Finally, what is the deployment plan?

We will be integrating source systems, potentially aggregation systems, and then consuming systems into the identity program.  A good project manager will be necessary to map out all the components and to help shepherd to work forward.  We must include an abundance of awareness.  Users get very attached to their ids and will be very unhappy if there are issues accessing their key systems.

So, the preparation is in place and we are finally ready to start building.  Next time, in the final installment, construction begins.

Post a Comment

Your email is never published nor shared. Required fields are marked *

*
*