For many years now, the Identirati have talked about the many reasons why Identity and Access Management (IAM) projects fail. Close to three years ago, we created our top ten pitfalls of an IAM initiative, which was the precursor to our advisory services business.Usability

In my view, one of the main drawbacks has been that IAM was never conceived as a business application itself. This is a fundamental flaw.

For IAM to succeed, it needs to break away from the notion that identity lifecycle events (such as adds, transfers, leaves and terminations) will flow from other business applications into the IAM system, such that it can do what it should. This is not truly how the enterprise works, not even for managing its internal workforce.

In most cases, events (requests for access and such) are constantly occurring and they are triggered by the end users - not by a system. Therefore, IAM needs to interface with these end users in order to enable them to gain the access they need quickly, efficiently and in a way that satisfies the governance posture of the enterprise (i.e. with the right approval and check-and-balances).

This means that IAM needs to be rewritten from the ground-up as a business application. As we state on our web site, we believe that today’s IAM user interfaces suck mainly because they were originally conceived as tools for administrators or developers to interact with, when they should have been designed for non-technical users. This was one of my points in the “fit-for-purpose IDM” blog series I wrote.

Assuming that you agree with me that the new IAM, needs to be usable, then here are some considerations I would like to bring up for discussion.

What would make IAM usable?

There are certain design considerations to take into account when designing IAM with usability in mind.  At the top of the list is defining the actors that will interact with it - who do we need to cater to?

Requester and Approver

The business user that IAM will serve nowadays is an extremely busy person, who on a daily basis has to respond to a ever-growing email inbox queue and is responsible for a team of people (whether they are her direct reports, her project team members or users of the SaaS application she is responsible for). This person has a large number of tasks to tackle in a typical day, and all she wants is to Get Stuff Done (GSD).  The least she wants to do is to spend a significant portion of her day wrestling with an access request interface that is not intuitive, requires way too many clicks to accomplish common tasks, and that does not display information in a meaningful way.  The net result of allof this is the user creating insecure shortcuts to get stuff done: either “copy all of the access that Bob has onto Mike”, or “let’s give Mike all access right now”.

For this person, IAM should be a very efficient system.   It should learn over time rather than be told explicitly what to do. Requestable items should be searchable in multiple ways, much like the Amazon.com store.  And for the most part, the system should be able to infer what items the user may be looking for and make the appropriate recommendations. Within a single click, the user should be able to find the person on whose behalf she wants to request access - and within another click, should be able to select all the accesses that makes the most sense for this person.  That’s it, quickly get in and get out.

This user needs to get back to GSD, so IAM needs to get out of the way. How? Here are some ways:

  • A single access request submission should be able to take care of more than one user if needed.

  • There should be clear visualization of what things the user needs to do, such as approving requests, versus things that are more FYI

  • The user interface needs to be clean and visually appealing to the user, especially when things are getting tackled. Nothing beats the sense of satisfaction you get when you clearer your unread emails from your inbox. Gmail’s UI is a good example of how to achieve this effect.

App Owner and Business Manager

IAM, defined as I proposed in a recent blog, encompasses Identity and Access Governance (IAG). Therefore, access recertification is and will continue to be a key core functionality. It is a key control in ensuring that users have the access they need and nothing more, and that runaway access is removed when no longer needed.

But those that ultimately need to attest to other user’s access are also non-technical users in most cases, so their interaction needs to be efficient and pleasant with the tool.

Very often, there are just so many items that are part of the access recertification that users are overwhelmed not only by the high volume in their queue, but also by the fast approaching deadline to complete the recertification. This all leads to rubber stamping, which defeats the whole point of doing access recertification.

Therefore, a new and more intelligent approach is necessary. Creating a solution that simply makes the user experience "more pleasant" than what current solutions deliver will ultimately fail.  The right solution will require a radically different approach to solving the problem - an approach that is razor focused on the end user.

To more accurate describe this new approach, we will need a separate blog altogether, but below I scratch the surface on some of the attributes this new solution should have:

  • It considers algorithms, such as risk scores to sort through the recertification queue to ensure that those items that need the most attention are at the top. A heat map is a good way to visualize this

  • It understands that access recertifications are done over a period of time, so that the end user is made aware of the progress made and the time left to complete, with some intelligent suggestion by the system on how to complete on time

  • Rather than letting things accumulate to create a rush closer to the deadline, the solution tries to motivate the end user to take action proactively. Very similar to how the Nike Fueld Band gets people motivated to hit a certain level of activity daily, the solution should attempt to set and track daily goals for the user to hitNikeFuelBand

  • Recertification should be optimized by calculating deltas, if a user’s entitlement sets has not changed since the last access recertification, the manager should not have to recertify much or anything for this user, the IAM solution should facilitate this

  • It should try to make this process event-driven, rather than scheduled-driven whenever feasible. For instance, if a person’s title or department changed, this event should trigger a proactive access recertification cycle for this user, which will then reduce the overall volume of attestation requests.

As you would suspect these are a few of the design considerations that have shaped our own product: SCUID Lifecycle.

I would love to hear your opinions on this topic, and any usability related suggestions or concerns that you may want to share.

 

SCUID Lifecycle Data Sheet

Frank Villavicencio

Frank Villavicencio