Authenticating external users in VSTS

A typical scenario for users of VSTS (Visual Studio Team Services, formerly Visual Studio Online) need free access to external users. For example, a company that hires vendors for outsourced software development needs to grant access to teams in the supplier who will act in the projects stored in your VSTS.

VSTS allows this problem to be solved from different ways, which vary according to the ease of implementation and convenience in use. Come take a look in this post how to enable this scenario in his account of VSTS.

As mentioned above, the VSTS is extremely flexible in terms of authentication model. This means that there are several ways of solving the access of external users (people outside your company) to its corporate account of VSTS. In this post I will discuss some of the possible approaches:

  1. Basic scenario: MSA Users
  2. Intermediate scenario: Azure simple SSO AD without
  3. Advanced scenario: Azure Federated SSO with AD

For each of these scenarios, we assume the existence of two entities:

  • The client: Our client is the fictitious company "customer Demo L3". The VSTS account is clientedemol3.visualstudio.com and your domain AD is clientedemol3.onmicrosoft.com Azure. Our client has a user "admin" responsible for the administration of the ADF and VSTS account domain. His email is [email protected]. This same user has a Microsoft Account associated with the email adm[email protected].
  • Supplier: the supplier will be the Lambda3, of coursAlegree. The domain AD Lambda3 Azure, in our example, is the lambda3.com.br. Already the Lambda3 user I will (Igor Abbot), with the email igor.abade[arroba]lambda3.com.br.

But what do we see? I want to show you how the customer Demo L3 could give access to an external user-in our example, I – so he could perform in a project in your VSTS clientedemol3.visualstudio.com. As you can imagine, this is a fairly common scenario for us, since our developers and/or ALM consultants require access to the accounts of VSTS our customers whenever we participate in any project.

Basic scenario: MSA Users

The first scenario considers a client who, for some reason, choose not to use a field Azure AD integrated into VSTS to manage the identities of its developers. This is the simplest scenario of all, since it depends only on the account of VSTS. Actually, when VSTS was released (when it was still called VSO), this was the only possible scenario. The ADF support came only after.

When there is no ADF directory associated with an account, VSTS identities need to be Microsoft Accounts ("Microsoft Account" or MSA). It means that anyone who wants to access our fictional account clientedemol3.visualstudio.com needs, first, create a Microsoft Account in account.microsoft.com. In the early days of VSO VSTS was how we did here in Lambda3:

  • Created an account with Microsoft e-mail from Lambda3 (in this case, igor.abad[arroba]elambda3.com.br);
  • Added ("invited") the user/email on VSTS client account (clientedemol3.visualstudio.com);
  • When I wanted to access the customer's account, do the login with my MSA.

Adding a Microsoft VSTS client Demo at L3
Adding a Microsoft VSTS client Demo at L3 (click to enlarge)

Although quite simple, this model has a few problems:

  1. Two different identities. Although I have a Microsoft Account with a user name identical to the one I use in the internal domain Lambda3, they are actually two different things. So I had to keep two sets of credentials, managing two passwords in two completely different systems. This brings us to the second problem, which is …
  2. Lack of "single sign-on". How are two different accounts, be authenticated in the domain of Lambda3 wasn't enough. I need to authenticate again when I wanted to access the VSTS client account. In addition, the MSA account belongs to me, not to the company. With this, it is not possible to make any kind of corporate management for that user. Obvious things, how to block a user when he shut down the company, are impossible when using MSA accounts. Finally …
  3. Personal identity (non-corporate). As we said, the MSA belong to the individuals who created them and not to the companies. In this way, there is absolutely no corporate control (such as password policy or account lockout) that can be done for you.

Obviously this model is not ideal for a company and, therefore, Microsoft extended the service to offer an enterprise-level solution to access VSTS – integration with the ADF.

Intermediate scenario: Azure simple SSO AD without

Customers using the Azure VSTS integrated AD (see how to integrate the two here) do not depend on more Microsoft accounts to give access to your account from the VS Team Services. Instead, they use your domain account in the cloud. The most important benefit of this is that identity management is no longer distributed (as with the MSA Accounts, where each user creates and cares for their own account) and happens to be centered (the user creation and management is done by the domain administrator AAD). In fact, many companies began to consider using the VSTS after ADF support because of their need to manage identities and access in a more "corporate".

When the Azure AD enters the equation, everything changes. The identity control is no longer done in VSTS and passes it to the directory in Azure. The first consequence of this is that you no longer have the option to continue simply adding Microsoft VSTS Accounts. All accounts need not necessarily come from the directory.

This premise-"all the accounts must come from the directory"-leaves us with two options:

  1. To continue using Microsoft Accounts (MSA);
  2. Create local users in the domain.

To continue using Microsoft Accounts (MSA)

"Huh?", you might be wondering. "But he did not just say that you can't use MSA accounts?"

Well, what I said is that you can't just add MSA accounts. But with a bit of complication, everything works. Alegre

What changes is that, before you add an account MSA to VSTS we first need to add it to the ADF. That is, only one more step and the process continues as we saw above.

Visit the classic Azure Portal and go to the Administration page of your directory. On the Users we will include access to an MSA account to the domain:

To add a user to the ADF access the MSA classic Azure Portal and indicate the type of user (1) and the MSA account email (2)
To add a user to the ADF access the MSA classic Azure Portal and indicate the type of user (1) and the MSA account email (2) (click to enlarge)

Once added the user to the ADF, now you just go on the screen of the VSTS user and add the user normally. He will be listed as part of the domain of the ADA.

Create local users in the field

A better option, so that you don't have to depend on MSA Accounts, is to create local accounts on the Azure AD. Thus, the responsibility of creating access ceases to be the supplier and developer becomes the client — that retains control over this identity.

Returning to our example: instead of creating an account with my email from MSA Lambda3, my client would create a user for me ([email protected]om) in his domain:

Create a new user in the ADF. A common pattern is to put the user name and company name
Create a new user in the ADF. A common pattern is to put the user name and the company name (click to enlarge)

To create a user in the Azure is also your AD must be informed friendly name and its role:

Details of the new user. Tip: be sure to identify the company (1), paper-which should be User (2) and optionally authentication support multi-factor algorithm (3)
Details of the new user. Tip: be sure to identify the company (1), paper-which should be User (2) and optionally authentication support multi-factor algorithm (3) (click to enlarge)

Again (we're already getting stars!): Once added the user to the ADF, now you just go on the screen of the VSTS user and add the user normally.

Advanced scenario: Azure Federated SSO with AD

This is, by far, the coolest setting. In fact, this is exactly the scenario that we have with some of our most important customers. Not only the client is integrated into VSTS Azure AD, but he is also integrated to our Azure AD. With that in addition to all the benefits of security and managing the Azure Active Directory offers, we have access to something pretty cool: single sign-on via ADFS.

When using federated access in Azure AD, can I connect to all ADF-backed services (such as VSTS, Office 365, Dynamics CRM, Yammer and others) using my internal AD domain credentials (on-premises) of Lambda3. With the correct configuration in your browser, no need to enter username and password to access any of these services. Integrated Windows authentication #ftw, baby!

The basic principle is: establishes a trust relationship between the domains customer and supplier ADF, so that the users in the domain of the client can add users who belong to the domain of the supplier.

That trust, however, is different from that network administrators are accustomed to do when it comes to AD domains. In the AD, we treat that Azure in two different ways:

  1. Common user in two domains
  2. Invitations Azure Active Directory B2B

Common user in two domains

Until quite recently this was the only way to establish a trust relationship between two domains ADF in order to add users from one domain to another domain B: both would need to have a common user X to be administrator of users in domain B.

In other words: to add the directory ' clientedemol3 ' a user coming from the domain ' lambda3 ', the clientedemol3 directory administrator is a member of lambda3 directory. Is the Act of adding the admin of clientedemol3 in the directory lambda3 establishing the trust – just that, nothing more is necessary. You can infer, however, that with this we end up in a dilemma of "chicken or egg" as a directory depends on the other. Therefore, in principle depend on a third party that can be trusted for both the clientedemol3 and the directory lambda3. And it is Microsoft. Alegre

Explaining better: so that our client can add admin users that exist in the field of Lambda3, proceed as follows:

  1. Add a Microsoft Account as administrator of users on clientedemol3;
  2. Add the same account as a user in lambda3;
  3. Add lambda3 users in the ADF to clientedemol3.

See the step-by-step illustrated below:

Start by adding the MSA account to the domain of the client
Start by adding the MSA account to the domain of the client

Don't forget to configure the account as User Admin
Don't forget to configure the account as User Admin

Now do the same on lambda3 domain. This time, however add the user in the role of User
Now do the same on lambda3 domain. This time, however, add the user to the role of User

Ready! Now go back to the domain clientedemol3 (logged in as adm-clientedemol3@outlook.com) and register the domain users lambda3 (1), stating simply your email (2)
Ready! Now go back to the domain clientedemol3 (logged in as [email protected]tlook.com) and register the domain users lambda3 (1), stating simply your email (2)

And just to not lose the habit: Once added the user to the ADF, now you just go on the screen of the VSTS user and add the user normally.

Invitations Azure Active Directory B2B

If you managed to get here, realized that allow external users access to an account of VSTS is far from something simple and consistent, even if it's something relatively common and that tends to be seen more and more around, as companies begin to lose the fear of cloud and take their workloads there. Aware of the importance of cross-domain Federation (for all the reasons that we've seen throughout this post), Microsoft began to invest in the ultimate solution to treat consistently this trust relationship between tenants Azure AD: the Azure Active Directory B2B Collaboration.

In a nutshell, the Azure is the B2B AD Microsoft tool to integrate identities between companies through simplified configuration and management mechanisms. In the future I'll probably do a post about it. At the moment, if you want to know more about how the Azure B2B AD works, watch this video.

In the words of Microsoft:

[O Azure AD B2B collaboration] simplifies management and improves security of partner access to corporate resources including SaaS apps such as Office 365, Salesforce and more, Azure Services and every mobile, cloud and on-premises claims-aware application. B2B collaboration improves security, the partners manage their own accounts and enterprises can apply security policies to partner identities access.

Azure Active Directory B2B collaboration is easy to configure with simplified signup for partners of all sizes even if they don't have their own Azure AD via an email-verified process. It is also easy to maintain with no external directories or per partner federation configurations.

To use the Azure B2B AD with VSTS, we will use the model of invitations by email. The advantage of this approach, when compared with the previous one, is that we don't need to add the Microsoft Administrator Account of our customer in our area so it can invite our developers. Much better, no?

Let's start by creating the invitations. In the preview version (currently the Azure are in public preview B2B AD) you must create a CSV file with the list of users who will be invited. The admin client, starting from a sample file, build a CSV as the below to invite Lambda3 developers. That is, although in the example below it is inviting only me, could have invited several developers/consultants for a time. Another advantage of the Azure model B2B AD user in two areas.

CSV file for invitation to the Azure B2B AD, open in Excel
CSV file for invitation to the Azure B2B AD, open in Excel (click to enlarge)

With the CSV prepared, between the option of adding the Azure Portal users to do upload the CSV:

In the add user dialog, select the option to partner companies (1) and load the CSV file that we create (2)
In the add user dialog, select the option to partner companies (1) and load the CSV file you created (2) (click to enlarge)

After the CSV upload, you have access to a report where you can track the shipping process and accept the invitations:

Monitoring report of Azure AD B2B invitations
Monitoring report of Azure AD B2B invitations

Each of the developers get an email with the invitation. By accepting, is automatically redirected to the VSTS client.

E-mail invitation sent by Azure B2B AD
E-mail invitation sent by Azure B2B AD (click to enlarge)

To complete the process: once the invitation has been accepted (and, therefore, the user has been added to the ADF), now you just go on the screen of the VSTS user and add the user normally.

In conclusion …

This post turned out much longer than I expected when I started writing it, but I thought I should register here that knowledge that – frankly – I didn't think consolidated anywhere.

And you, dear reader? There's a similar situation in your company? What do you think of these tips? Leave your comment!

 

A hug,
Igor

Author: Igor Abade

Igor Abade V. Leite ([email protected]) is a Visual Studio ALM MVP (Microsoft Most Valuable Professional) since 2006. Speaker at various Software Development community events (TechEd Brasil, The Developers’ Conference, DevOps Summit Brasil, Agile Brazil, Visual Studio Summit, QCON among others), has also written articles in magazines and websites such as MSDN Brazil. Since March/2011 is one of the owners of Lambda3, a Brazilian consulting company specialized in ALM, software development and training. Visit his blog about VS ALM at http://www.tshooter.com.br/ and follow him on Twitter @igorabade.

Leave your comment!