Centralized Identity

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.

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

SOLUTION:
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.

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.

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

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.