Centralized Identity

giving users access to all of AppDynamics' services and products through one login
Centralized Identity
AppDynamics, a Cisco company, is an application performance monitoring company. The Controller is our core product- where users can go to view their application data and to troubleshoot when there's an issue. Currently, all of our features that require a login to access (eg. Controllers, Accounts, University) can have different credentials. We aim to have a centralized login, so all of AppDynamics' offerings can be accessed with one login.
Product Designer:
UX Strategy, User Research, Wireframing, Visual Design, Interaction Design, Prototyping
UX Researcher
Product Manager
5+ Engineers
Fig 1. New users' migration to centralized identity flow
Fig2. Existing users' migration to centralized identity flow
Currently, all of AppDynamics' features and services have different logins. Between Controllers (users can have multiple controller accounts), Accounts, and University, users need to remember multiple login information. This can make it extremely difficult for our users as remembering multiple credentials can take away from the task at hand. Admins also will now need to manage identity settings in multiple places now. This makes our customers worried about security risks since identities are being propagated to AppDynamics in multiple places.
Fig3. Current flow for customers who utilize SAML for their Controller accounts
Fig4. Current flow for customers who leverage the internal IdP in the controller
For an end user, the best case is that they have 2 logins, one for Accounts and one for Controller accounts. For a customer admin, each Controllers' user permissions and SAML setup needs to be handled in its specific Controller account, so they will have n+1(n=number of Controllers and 1 is for the Accounts experience) locations to manage user permissions and conduct SAML setup. We punt identity to our customers space though because customers setup SAML in SAAS and OnPrem Controller accounts.
For an admin, the worst case in this situation would be the same as they would still have n+1 locations to manage user permissions and SAML setup. But, in this flow, customers leverage AppDynamics for its identity provider so user identity is stored in every Controller account and in the Accounts experience. Also, for the end user, they too will have to know and manage n+1 sets of credentials.
Our solution is to have 1 identity for all of AppDynamics' services. We would want our customers to bring their own identity platform (which most do) and to integrate it or federate with AppDynamics, and in doing so, users have 1 identity and it would live on the customers' space. This way users will not have to remember multiple login information, and customers will feel more secure that all of the user identity information lives within their own space and isn't stored within AppDynamics. Users will have a single, global user profile, and we will now have a true SSO to all of our Controllers and all of Accounts experiences. With one true single user identity, we can now provide things such as personalized onboarding, personalized notifications, universal user preferences (language, time zone), and universal security configuration (2 Factor Authentication, password policy, etc).
Fig5. Flow of users having one login
Users will have 2 options: the first being that most of our customers will integrate their own identity platform with AppDynamics, so that all of their user identities will live in their space, and the second being that for the customers who don't want to integrate their identity platform with AppDynamics, they can leverage an AppDynamics provided identity platform. Either way there will be only 1 single user identity now and one place to manage identity settings and user permissions.
There are 3 different areas we could look to to see if we have succeeded with our experience. The first being a decrease in the number of password resets. We currently have a high volume of password resets, presumably because users have many different credentials to remember for all of AppDynamics' services.

The second item we would want is a decrease in the percentage of users that have logged into multiple controllers. Currently for US SAAS users, the percentage that have logged into multiple controllers is 25%. Also, 100% of users had a different account than that of their Controller. So, users have at least 2 different sets of credentials.

The last item we would want is a decrease in the percentage of users that have to be managed in multiple places. 25% have logged into multiple controllers. Of that 25%, 2% had logged into 5 of more Controllers, the max being 12. Meaning, that user needs to be managed in 12 different places now. Talk about a nightmare!
This central identity initiative is too big to be tackling everything together at one time. So, we created sub-initiatives that would allow us to tackle this in chunks and allow us to be more agile.
Phase 1
The goal of phase 1 is to make sure newly created SAAS users are created and authenticated through the AppDynamics Idp. These users will be authenticated by AppDynamics and not through the customers' Idp. As a result of this, new users will have gained a single identity across any SAAS Controllers their accounts are linked to and the Accounts experience.

Many of the users in our SAAS Controller accounts don't have complete or verified emails, because it was not required before. It is required now, but there is no data validation to ensure that the information entered is correct. To move to a centralized identity, we will need to make sure we obtain verified email addresses. In phase 1, we are tackling new users only. So, in the new flow, anytime an Admin adds a new user, they will have to enter an email for that user. That user will get an email with instructions on creating a password. Once the password is created, they will have an active account in the new central identity world.
Fig6. New user creation screen with data validation
Fig7. Create password screen to activate their account
Phase 2
The goal of phase 2 is to make sure existing users are moved seamlessly to new AppDynamics IdP that will allow users to have a single identity across the Controller accounts and the Accounts experience. We will correlate users based on their verified email addresses and their company billing account so that users won't lose access to their accounts after moving to a single identity.

Just like in phase 1, all users need to have a verified email address. To tackle this issue, we will make users verify their email addresses when they try to login to the Controller account. When a user goes to a Controller account and enters in the company account name and their credentials, they will be prompted with a message letting them know about the migration process and that they need to verify their email address. Once they enter their email address, they will get an email asking them to setup a new password which will be used to access this Controller account and the Accounts experience.
Fig8. Login screen that lets users know of the migration process and asks them to verify their email addresses
email templatemock
Fig9. Email template sent to users
Fig10. Password creation screen to enable single identity for Controller and Accounts experience
Phase 3
The goal of phase 3 is to create a single identity for our SAML customers. These customers currently have 2 user identities: in Accounts and in their space. But, user permissions are still done for each user in the different controls. They currently can only setup SAML in the Controllers but not in Accounts, resulting in these 2 identities. We aim to allow Accounts admins to federate their SAML identity provider to the Accounts experience, creating a single identity in the customers' space.

In the Accounts experience, there will be a new section for Identity Settings which will have support for SAML federation. From here, the customer will need to export or manually enter the AppDynamics service provider metadata into their identity provider and import their identity service metadata into Accounts. After completing the attribute mapping settings, SAML federation can be activated.
Fig11. SAML federation screen
While designs have been created for all 3 phases, only phase 1 has been built so far and will be launched soon. The overall idea has been conveyed to the engineers, and they see no issues with the designs created for phase 2 and 3. But, as engineers continue to work on these 2 phases, I'm sure engineering limitations will need to alter the designs that have been created thus far.


Role Based Access Controls


User Management