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:
- Basic scenario: MSA Users
- Intermediate scenario: Azure simple SSO AD without
- 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 course. 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.
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 da
ys 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.
Although quite simple, this model has a few problems:
- 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 …
- 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 …
- 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.
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:
- To continue using Microsoft Accounts (MSA);
- 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.
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:
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:
To create a user in the Azure is also your AD must be informed friendly name and its role:
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:
- Common user in two domains
- 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.
Explaining better: so that our client can add admin users that exist in the field of Lambda3, proceed as follows:
- Add a Microsoft Account as administrator of users on clientedemol3;
- Add the same account as a user in lambda3;
- Add lambda3 users in the ADF to clientedemol3.
See the step-by-step illustrated below:
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.
With the CSV prepared, between the option of adding the Azure Portal users to do upload the CSV:
After the CSV upload, you have access to a report where you can track the shipping process and accept the invitations:
Each of the developers get an email with the invitation. By accepting, is automatically redirected to the VSTS client.
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!