Improved alternate authentication experience for Visual Studio Team Services (VSTS)

Justin Marks

Recently, we’ve heard feedback from customers that developers have a poor experience creating and managing their alternate authentication credentials and that administrators moving from TFS to the cloud aren’t provided the policies they need to enforce how alternate authentication is used by their end users.  This post will describe our plans to provide a better E2E experience for end users as well as improved administrative experiences for administrators.

This post is intended to be a preview of what we’re planning on building over the next quarter.  As always, the timelines and designs are subject to change.

For those of you unfamiliar with what alternate authentication is, I’ll provide a quick refresher to set the stage for what we’re are talking about…   When logging into VSTS or other Microsoft services, users are presented with a login screen provided by the Azure Identity team.  Most users are familiar with this screen as it is common across all Microsoft web properties as well 1st party client applications. There are, however, some developer centric scenarios where this login experience is not presented to the user, namely when using 3rd party tools like Xcode on a Mac or Git.exe on Linux where basic credentials are expected.  This is where alternate authentication credential come in.  VSTS provides 3 industry standard solutions: Basic username/password credentials, Personal access tokens (PATs) and SSH keys and they’re used by roughly 1/3 of our active customers.  Many of you may use these without even knowing it since Git for windows comes with the Git Credential Manager which leverages PATs under the hood.

End users/developers

When talking with our end users, we’ve heard some common themes emerge: PATs expire without notification, Scopes and the experience overall is hard to understand.

We’ve taken this feedback and are focusing on revamping the experience centered around three key scenarios:

User generates a personal access token

We’re focused on providing an easier to understand creation experience that guides the user through creation of a new PAT.  The new creation allows you to create a PAT that expires on the date of your choice (assuming it meets administrative policy discussed below) or never expires at all.

Scopes will be grouped by area of the product and inline help will be provided so you don’t have to read through external documentation to understand what a given scope does.  We’re also standardizing much of the terminology used to add consistency and aid with ease of understanding.

The list view is being improved to include more information about each PAT including the list of scopes, accounts the PAT can be used on, and the last used date and IP address.

For users that are heavy users of PATs, the page will include a filter control where you can opt-in to loading expired or revoked PATs.

User is notified of an expiring PAT

When a PAT is nearing expiration, you’ll get an email notification giving you the ability to immediately take action and extend the lifetime of the PAT so that your tools and processes relying on it will go on uninterrupted.

User manages their PATs

For a given PAT, you’ll be able to edit not only the name and expiration date, but the set of scopes the PAT allows as well.

For the times when you’ve forgotten the PAT token but don’t want to refill the creation form, we’re providing the ability to “regenerate” a PAT which revokes the existing token and provides a new one with the same scopes as the original.

In addition to these PAT focused scenarios, we’re going to take the opportunity to update the SSH and Basic credential experiences as well to match the new UX styles.

Administrators

Similarly, when talking with VSTS administrators, some common themes emerge: Alternate authentication must honor Azure conditional access policy (CAP), Administrators want to set and control policy (e.g. lifetime), Administrators must be able to restrict who can create PATs.

Administrator audits PAT

Regarding the first point, VSTS began supporting CAP in February with the caveat that alternate authentication falls outside the control of CAP.  We are actively working with the AzureAD team to fill this gap but we want to provide a way for administrators to manage the risk immediately.  We plan to provide APIs that administrators can monitor and apply their own business logic on top of.  The API will return what actions a given user performed, from what IP they took the action, and with what authentication type.

Administrator manages policy

Every organization has their own security guidelines in place and VSTS wants to provide the necessary dials for administrators to customize the experience to comply.  We plan on adding new policies to allow administrators to manage the maximum lifetime for tokens including allows organizations to allow never expiring PATs.  We also want to provide similar policies for basic auth as well as SSH keys.

Administrator revokes PATs for a compromised user

In the unfortunate case where a user’s alternate authentication credentials are compromised, administrators must either remove the user’s access to VSTS or contact VSTS support to have their credentials revoked.  We want to make this self-service for administrators by adding this functionality to the users hub; an administrator will be able to drill into a given user and revoke any of their alternate authentication credentials.

I hope this gives you some insight into our plans over the coming months.  Stay tuned to the release notes to see when these features will rollout to your account

• Justin

Justin Marks Principal Program Manager, Azure DevOps

Follow