SecureAuth® Adaptive Policies

A key feature of the SecureAuth Identity Platform, Adaptive Authentication allowed SecureAuth Admins to configure a series of programatic rules and checks that helped to verify or ensure a users identity before, during, and after a user logged into an application or system connected to the platform.

I researched and developed a UI design that leveraged both the technology from two existing iterations of the feature and customer needs as expressed through user interviews about the existing technology and usability testing of possible updated UI ideas.

TIMELINE: 1.5 YEARS (ONGOING)

MY ROLE

I was the design lead on the project and was responsible for developing the design strategy, contributing and overseeing design execution, and leading UX research efforts.

As such, I conducted most of the research interviews, developed research study plans, oversaw design development and usability testing, managed and coached junior designers on design for the feature, and was responsible for communicating out the design vision for the project to the organization at large.

Research & Problem Definition

The team conducted a number of customer and internal stakeholder interviews to assess and understand both how the underlying authentication systems worked as well as how customers desired to use the system within their organizations. A summary of the challenges we had with the underlying technology systems, as presented to internal stakeholders, are below:

KEY customer Findings

Ultimately, our customers didn’t really care as much about how the system worked and struggled to do so. Both of our previous design iterations were heavily biased toward reflecting how the backend systems worked to the admins, but both were ultimately difficult for admins to learn and accurately configure.

Based on feedback from customer interviews we concluded that there were two common mental models for how system admins thought about organizing authentications:

• By user groups — privileges and authentication rights were granted based on who you were within a company or organization — admin, executive, manager, individual contributor, etc. or

• By application groups — certain applications required more stringent authentication bc they were considered critical systems vs systems that everyone needed to access.

In larger orgs, system admins needed a way to blend both of these configurations together in order to reduce risk in fraudulent authentications to they software and systems.

Solutions

I started by separating out all settings that were related to grouping or managing users or applications for authentication rules. This was a natural by-product of the re-architecture of the platform itself, but also helped to reduce confusion from the legacy system around having to configure these settings with every new application integration. This left a few things specific settings to be configured with our natural language authentication rules:

• Credential Requirements — whatever evidence an organization wanted to use to verify a persons identity. Within the existing systems, in addition to the traditional password, we supported things like digital tokens, third-party security keys like Yubikey, and single-use passcodes.

• Authentication Rules — these were non-user controlled configurations that previously could be used to analyze an authentication and allow someone to either bypass or be require to enter a specific credential during login. Examples of authentication rules were white-listed IP addresses, calculated velocity between recent login attempts, and IP threat feed data.

POLICIES CONCEPT

We then borrowed from our customers existing terminology and mental models around the idea of creating “policies” for system privileges and segregation of duties. That’s authentication jargon for making sure that people with high-level privileges can’t intentionally or unintentionally do things like… create an account that is payable and approve payments to that account (see the 1999 film Office Space for a fantastic example of the kind of things this is trying to prevent… it’s also a very entertaining film if you haven’t yet seen it).

In the original design a policy could be configured for either a specific user group, authentication group, or combination of the two by simply assigning the policy to those specific groups. In cases of a conflict, the system would default to the most restrictive policy to ensure the security of the system.

Due to the technical restrictions of the legacy system we had to build on top of policies could only be directly associated with individual application integrations. While simpler, it did not meet the needs of our customers who needed to create specific policies for users with high-level access within certain applications.

Simplification of authentication rules

To help users understand how the authentication rules would get analyzed and to provide better predictability for how a policy would compute a result, I originally designed rules to work directly with credential requirements—only assessing for conditions where a requirement could be skipped. This can be seen in the “Challenges” screenshot above.

Unfortunately the legacy system was unable to support this type of configuration and I had to adjust the design to match the constraints of that system. As a compromise, we were still able to simplify actions taken on authentication rules to be either “skip” or “prompt” for a credential vs the list of six or so options that admins could chose from in the legacy system. A separate list of rules could be created for conditions where an admin would want to “block” and authentication into an application or system. Blocking rules were always analyzed first to help admins configuring the system to be able to better understand and predict how a policy would ultimately net out in any given scenario.

Credential requirements unfortunately could not be per rule set and had to be moved to be per policy. While this made the system a bit more rigid than the original design, it ultimately allowed for easier migration of existing customer systems into the new product.

Results

While I never got to see this part of the product be released during my tenure at SecureAuth, we did manage to stand up a working version of the feature in dev environments (video of that below) and initial usability studies with admin customers indicated that they were able to understand and adapt many of their existing manually managed policies into the proposed solution. They were also able to more accurately describe what they believed was configured for a given policy.