In this monthâ€™s Introduction, three workflow sets were introduced:
- Provisioning and deprovisioning (which I abbreviate as de/provisioning)
- Non-employee management
- User or access recertification
This segment explores the first of these, de/provisioning)
De/provisioning is the most common of IAM workflows. Done right, this workflow delivers tremendous ROI, improved audit results and improved customer satisfaction by significantly speeding up the de/provisioning process. It is also the most complex, as a workflow has to be identified for each access or equipment type. Furthermore, for those access items that will be automated, instructions may have to be provided to the IAM system on how it needs to grant or remove access.
Letâ€™s now run through the objectives outlined in this monthâ€™s Introduction segment for this set of workflows.
Objective 1: Determine the appropriate scope
A workflow can be created for just about anything, but does it make sense to create one?
To begin answering this question, refer back to the previous lists of systems (created about seven months ago). Begin with the primary systems and move on to the secondary systems. Chances are, some degree of workflow will be needed for each one of these systems.
Also consider what manual workflows might be appropriate â€“ for example, for computers, mobile devices, application licenses, etc.
Another important input here is the companyâ€™s service catalog. If one exists and it has built-in workflow, a good portion of the work is already done. Not all of it, since the service catalog triggers tasks for manual de/provisioning only. But at least the workflows in the service catalog should give some sense of order of operations (i.e., which tasks can be performed concurrently and which must occur sequentially), and it should contain the names of the teams involved in each workflow.
For equipment workflows that will stay manual, the services in the service catalog may be replaced by or augmented with similar workflows in identity manager. For access workflows that will be automated, those teams will need to be engaged to better understand the technical details.
A note of caution â€“ be careful when approaching teams with an offer of automation. Those teams that are overwhelmed with work will very likely welcome the offer, but those that are less busy or if they perceive that their entire job will be automated will be understandably reticent to participate. They will perceive that youâ€™re coming in to eliminate their jobs. And yes, it will be that personal â€“ anyone on the IAM team will become persona non grata, bringer of pink slips.
It is worth spending time understanding how the IAM teamâ€™s efforts will be received, and engage management appropriately. This may also impact the scope of work, as items that should normally be included in scope or fully automated may have their scope reduced or be eliminated from scope if the political situation gets too volatile.
The questions that need to be answered for this objective are:
- Is a workflow going to be created for this item?
- If yes, will there be automation, or manual task assignments?
- What are the teams involved?
- How will the teams receive our efforts?
- Is there an existing workflow that can be leveraged?
Objective 2: Populate the requirements list
The requirements list must be clear based on the determined scope. If full integrations are expected with any systems, the technical expectations should be documented (if they havenâ€™t been already). Remember, not all IAM products are created equal, so selecting the one that best meets the requirements is vitally important.
Objective 3: Identify prep-work
There is quite a bit of prep-work that can be done to speed up implementation once a tool is selected. For example:
- Working with the people familiar with the de/provisioning processes to understand and streamline those processes â€“ are the processes usable as-is, or are they a mess or outdated?
- In particular, itâ€™s important to understand the deprovisioning process: can an account simply be deleted, or does it first need to be disabled for a time (e.g., to allow for data backups)? If there is a disabled status, what will be the duration for that one week? two weeks? a month?
- Similarly, can a piece of equipment be taken away directly, or are there data backup needs there too?
- Cleaning up existing service catalog workflows so they can be more easily transitioned (if applicable)
- Preparing target systems â€“ this is especially important on UNIX. Integrating UNIX systems will be much easier if the UIDs are already syncrhonized across the enterprise. If not, this is a good time to begin the cleanup effort. If this already got done as part of the March activity, great job!
- Also consider if directly integrating each UNIX box with IAM is optimal, or if an intermediary tool will be used to manage UNIX access via LDAP, Active Directory, or the mainframe.
In the next segment, we’ll explore the user/access recertification workflow set.