Why Is A Simplified End-User Experience Beneficial To All?

You are an Administrative Assistant on the first day of your new job. Your manager sends you the link to your new company’s access request site and asks you to request everything you will need to perform your duties. You log into the Identity Management (IDM) system to make a request and are immediately alarmed at the number of options and fields available.  Selecting any of these options brings you to a new page with the same number of options!  You start to contemplate asking a colleague what they requested or even begin to submit a few generic requests -- if only you can find where to submit them!

What Exactly Should An End-User See When Requesting Access?

Unfortunately, this scenario happens to end-users more often than we’d like to admit.  When considering a new Identity Management solution, or even reevaluating an existing solution for improvement, it’s important to keep this type of scenario in mind and set goals to reduce the complexities of access requests in the eyes of the end-user.

What exactly should an end-user see when requesting access? This is a common hurdle for teams when implementing an Identity solution. One overarching guideline for approaching this issue is to keep the interface simple. While this is not a new concept, it is often forgotten when attempting to provide a feature-rich solution. Remember, in general, less is more to an end-user.  

Most end-users are not frequenting the Identity Management solution, so there is little opportunity to transfer knowledge with it remembered for subsequent sessions. Even if there is no direct impact to security, an implementer should consider restricting view-permissions on screens, resources or attributes to only the necessary groups. In addition, the end-user should be provided choices and direction over free-form requests in order to make the requests meaningful, the fulfillment of manual processes more efficient and the setup of automated processes possible. This may require translations of attribute values to help the end-user understand the requests they are creating.

What impact do target resources have on this process? When developing the interface for end-users, implementers must consider that the Identity Management solution is dependant upon target resources for defining necessary form field values. Often these inputs are similar to what is supplied from the trusted source and can be transferred to the target resource behind the scenes within the Identity Management solution. However, some of these inputs are specific to the resource and must be specified on account creation or update.  

It may be possible to shift this responsibility away from the end-user by manipulating the target resource to default some of these values in certain situations. Target resource administrators may even be able to take this a step further by consolidating points of access control. For example, several application owners may choose to utilize a common repository to manage permissions allowing the Identity Management solution to interact with a single target system for all participating applications. Either approach may translate to the end-user as less to manage and remember. 

What if end-users are still confused by what they should request? It is not uncommon for end-users to know what job they must fulfill and still not know what access is needed for that job. This is especially true for ‘Day One’ employees. At this point, Role Based Access Control (RBAC) may be considered to further simplify the request system. Following this approach, roles would be defined to identify specific duties of an employee within an organization.  

Once defined, these roles can be mapped to all target resource permissions required to perform those duties. A user no longer has to request an individual piece of access from each target resource, only the role they need to fulfill. This makes the requests more intuitive by further automating the process and placing more of the technical attributes beyond the scope of end-user visibility. These benefits come at some cost, however. Significant effort may be required by a Business Analyst to initially define roles, approval workflows may become more complex and certifications may be necessary to maintain the roles (although that comes with additional benefits as well!). 

Can we eliminate end-user requests altogether? In most cases, this is not feasible. However, the number of requests may be greatly reduced by further automating processes in the Identity Management solution. Information from the Identity Management solution’s trusted source may be able to identify a number of roles applicable to a user.

This starts to form the basis for Attribute Based Access Control (ABAC) and the idea of birthright resources. Attributes of a user profile, specifying anything from a user’s position to the entire active user base, can be mapped to a set of roles. From this point, provisioning is carried out similar to RBAC. This may, for example, further alleviate ‘Day One’ basic access requests for new and transferred employees. Roles that are provisioned via ABAC can be removed from the request system, reducing the choices available to end users, while a RBAC approach can be utilized in parallel for the remaining roles.

The methods described above aim to reduce what is available to end-users when requesting access. By doing so, end-users are less likely to request inappropriate access or have requests stalled in approval or manual provisioning workflows due to inaccurate request descriptions. It also lends itself to a better user experience by limiting the training required to make an employee effective at utilizing the IDM system.

As the system evolves and begins to build upon each of these methods, Identity Management solution administrators will begin to focus more heavily on certification and segregation of duty definitions to maintain the relationships among attributes, roles and target resources.