Visit to the Workshop: A Do It Yourself Identity Management Solution (IdM)

One constraint to implementing third-party identity management solutions is cost. Once the moneychangers see the quote, particularly alongside the deployment timeline, the project is likely exiled to some corporate gulag of no return. Since you will need to conduct significant analysis, documentation and implementation work even with a vendor solution, we can, instead, wander out to the workshop and see if we can cobble together an IdM solution from bits and pieces of controls we might have lying around.However, as with any do-it-yourself project, preparation work must be comprehensive and well-executed or your project will fail.

Based on my experience, here is one path to success:

1) Document every type of user that requires system access.

Recall in an earlier post, that, unless you have compelling reasons to be more expansive, I recommended you minimize the population for which you manage identity to those for whom you expect to provide access to sensitive systems or for whom integrity or non-repudiation must be maintained. Be fairly expansive in your view of what is sensitive, but assume any application that requires a user login, all data stores with non-public data, all servers that host such data, all network devices, the entire development environment, your messaging clients and system logs are all in scope. Do not concern yourself at this time with deciding how to control access to these resources; just determine whose access to them you need to control.

2) Document how each of these user types joins the organization.

Depending on the size, geographic dispersal, technical architecture, and many other organizational factors that you must comprehend before starting this exercise, you may identify several varieties of source systems for employees, temp workers, contractors, consultants, affiliates, vendors and others. Identify key business and technical contacts for each system. Ideally, you will already have good working relationships with many as they represent the difference between your success or failure.

You want them on your side so only by understanding the processes they support and the challenges they face will you provide a compelling reason for them to change how they do what they do each day. It is in selling your plan where preparation will matter most. The likely entrance points for employees and temps, generally, the most numerous populations, are either centralized or distributed staffing or sourcing systems. While, as initial touch points for these populations of associates, they might seem likely partners in identity management since there are several challenges you must consider:

  • Many organizations outsource this work so your potential new hires may be commingled with those of other companies
  • Your source system for identity data must be a trusted one or you are assigning identities based on attributes of potentially low quality. HR and Payroll systems are persistently maintained to support ongoing operational needs so are likely to have some corrective mechanism for erroneous data – however, the recovery process for an identity may have already been compromised by the time the mistake is discovered and remediated
  • In addition, both are at least one step removed from the initial touch. Sourcing/staffing systems are intermittently maintained to meet a specific, immediate need – so ensure that data quality is maintained procedurally during input and through system edit check

So , I found most success with a centralized background check application – data quality was necessarily high, the data were retained permanently, and it represented a first touch for many user types – unfortunately few organizations are likely to have the luxury of staffing their own background investigations team.

3) Identify the benefits and constraints of each system for each user type it supports.

These may be technical or operational in nature. An example of a technical constraint is a legacy third-party system that may not be able to handle web services messages and, since the vendor no longer exists, no modifications of the code can be undertaken to provide the missing functionality. Operationally, the AP system might be the source for contractors, consultants and vendors, but much of the identity data may be at an entity level, rather than for individual users. Further, these users may float throughout the organization making their presence very difficult to track.

I will share in a future installment how to build a comprehensive contractor management system to address otherwise orphaned populations. Document the benefits and constraints in detail; you will need them to build use cases for your solution. Admittedly, these steps are likely beyond those you would undertake for a vendor IdM solution, but there are some significant benefits to this additional analysis, like gaining a greater understanding of your users and building relationships with key stakeholders in your program, and the costs are fairly negligible. Fortunately, most organizations have a limited number of entry points – though before you sigh in relief, some of them will have significant technical, if not operational hurdles.

An additional benefit of this approach is the analysis may help to lay the groundwork for replacing or enhancing some of these systems, potentially to the delight of the system users, but by conducting an incremental review, you have not spent the company’s money before deciding that identity management is a lost cause in organization and you will do well to get a new job before anyone else figures out how broken a place employs you.

Next time, we look at your existing directories, the provisioning chain, and systems that will consume the identity data. I know you are anxious to play with the tools, but, please be patient. I need to ensure no one will hurt themselves!

Post a Comment

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