Earlier this week Sean McBreen from the Visual Studio Online team posted an announcement detailing the work that he and his team have been doing to streamline the process of creating a new Visual Studio Online accounts where users can authenticate using their corporate username and password.
This scenario is enabled through Azure Active Directory (AAD) which allows for synchronisation of corporate identity information to the cloud which can then be used by SaaS applications such as Office 365, Dynamics CRM and now Visual Studio Online.
If you want to get up and running with Visual Studio Online quickly, and link it to your corporate directory I recommend that you read Sean’s post. The purpose this post is to show how enabling authentication with AAD in Visual Studio Online is not only great for organisations who want to us corporately controlled user names and passwords, but also for projects that span organisational boundaries. Really good examples are consulting companies and system integrators, and of course their customers.
Before I get into the detail of how to get federated identity working with Visual Studio Online I wanted to provide a little bit of the background on the journey Microsoft has taken so far with AAD support.
The release this week is actually a refinement (from a users perspective) on a capability that was released at the BUILD conference in April 2014. In April, Microsoft released a preview of the new Azure portal. In that preview it was possible to create a Visual Studio Online Team Project, and if one didn’t already exist, a Visual Studio Online account. Team Projects created through the preview portal were special however because they made use of AAD to authenticate users.
What’s Changed in This Update
Whilst it was great that we could get Visual Studio Online using AAD via the preview Azure portal, it didn’t really give us much control over which directory the Visual Studio Online account was associated against. This latest update firstly allows us to specific which AAD instance to associate the Visual Studio Online account against at the point of creation.
One of the quirks that I have noticed is that whilst you can have multiple Visual Studio Online accounts associated with a single Azure subscription, once you create your Visual Studio Online account and associate it with an AAD instance, all Visual Studio Online accounts within that subscription must be associated with that same subscription.
The work around which would enable you to freely associate different AAD instances with each Visual Studio Online account is to create multiple Azure subscriptions. Whilst this might sound complex creating a new subscription is easy and it does provide some benefits which we will get to shortly.
So now with all that background out of the way we finally get around to the whole reason for this post. Enabling users from different organisations (different AAD instances) to use the same Visual Studio Online account.
Reasons for Federation
Given that Visual Studio Online now supports AAD and Microsoft Accounts you might be wondering why federated identity is that important, surely anyone who doesn’t have an Organizational ID can just use an MSA? The following diagram shows how that topology would work.
While this is true it isn’t really optimal from a security perspective. Let’s say that you are the IT manager at your company. You have engaged the services of a system integrator to build a new line of business application and you decided to manage the project using Visual Studio Online. You create the Visual Studio Online account and associate it with your corporate directory. You then grant access to the individual MSA accounts from the system integrator. You’ve now optimised access to Visual Studio Online for your own staff, but in reality the majority of the users of the Visual Studio Online account are going to be users from the external system integrator. You could have instead opted to associate the Visual Studio Online subscription with the system integrators AAD instance but in the end you are going to want to bring maintenance of the solution in house.
There is another potentially more serious security concern. Imagine that one of the staff members of the system integrator is terminated on poor terms. Whilst the system integrator has probably disabled their corporate account they generally have no control over the MSA that staff member was using to access your systems. If the system integrator fails to advise you to shutdown access to the MSA then the former staff member still has access to your Visual Studio Online account.
Instead it would be better if, as IT manager you could link your AAD instance to that of the system integrators so that whenever one of their staff log into your Visual Studio Online account that they use their own corporate credentials. If that staff member leaves the organisation (for whatever reason) then their account would be disabled, and access to your Visual Studio Online account with it.
This doesn’t negate your obligation to regularly check who has access to your Visual Studio Online account, but it helps leverage the user management processes and workflows at your partner system integrator. It is also one less password for individuals to have to manage.
Getting Federation Working
Fortunately AAD supports the ability to add users from other AAD instances. When adding a user you have the option of creating a new user in the directory, adding a Microsoft Account, or adding a user from an external directory.
In order to add a user from an external directory the current user logged in performing the administrative task must have read access to that same external directory, otherwise it won’t be possible to validate the user that is being added. In practice what this means is that you can generally add users from other AAD instances within the same subscription, but not from another instance in another subscription controlled by a different organisation.
Here is the federation chicken and egg problem. You can’t add a user from a foreign directory because you can’t get read access to it, and the administrator of the foreign directory can’t grant access to you to read their directory for exactly the same reason.
So how do we move forward? Well the trick which was explained to me was to use an MSA and add it to both directories. You would then log into the user management portal using that MSA account and then add users from the foreign directory taking advantage of your user administrator status in the local directory and read access to the foreign directory.
When adding users you will now get a green tick next to the username indicating that AAD was able to successfully validate that user exists. Note that when you add a user from a foreign directory (or an MSA) you still need to provide some user details. This information is not kept in sync between the directories. Whilst this might be considered a problem it does allow you to suffix user descriptions with their organisation name which makes it easier to identify them in your systems as a foreign user (other than the username of course).
If the process above left you feeling slightly uncomfortable you are not alone. Let me explain why you might like to take a slightly different (and complex) approach in the interests of maintaining the integrity of each organisations AAD instance.
The problem with the scenario above is that someone is simultaneously given read access to the system integrator directory and user administrative rights on the customer directory. I don’t know of many IT managers in either organisation that would be too happy with that approach. In most circumstances it would be unacceptable to allow an external organisation to have control over your user directory. On the flip side, system integrators work with a variety of customers and often have internal distribution lists which detail client names and projects – also information that you wouldn’t want to share. So how do we enable federation without raising security concerns?
Sandboxing Projects and Relationships
The approach that I recommend is to create a separate Azure subscription. This subscription will contain a separate AAD instance which is associated with a Visual Studio Online account (also in the same subscription). Both organisations would then create their own MSAs with user-level access to their own AAD instances. Both MSAs would be granted user admin rights to the new AAD instance and could login and grant rights to other users from within their organisation. As an added security measure you might initially add project leaders from both organisations and grant them user admin rights and then disable the MSA accounts ensuring that all users from that point forward make user of their Organizational IDs and the benefits associated with them.
Another nice side effect of this approach is that casual users who may not have an Azure Active Directory instance can be added to this new AAD instance via an MSA. Having a separate Azure subscription for the project or vendor relationship is also handy from a development infrastructure point of view. The development team can use the Azure subscription to deploy their solution to the cloud and have all of the costs associated with the project contained within one sandbox.
Support for Azure Active Directory support was right at the top of my wish list for Visual Studio Online and I’m excited to now have this capability. The ability to enable federated identity scenarios is also going to be very useful for consulting organizations and system integrators.
I do wish that establishing relationships between AAD instances was easier. Perhaps Azure could be extended to support sending “federation invitations” where a user with sufficient rights In a remote directory could grant the ability for an AAD instance to check username validity without having to go through the whole MSA workaround.
The content in this post was heavily influenced by some work I did with the Visual Studio Online team around guidance for consulting organisations and system integrators. Now that AAD support has been shipped for Visual Studio Online some of that guidance might need to be updated. Specifically I think that the more favourable pattern for organisations wishing to support federated identity is the Account per Customer / Account per Vendor pattern. Like everything its a matter of trade offs though.
If you take this post, and the patterns outlined in that document you should have a good foundation for getting Visual Studio Online up and running for you and your organisation regardless of whether you are a system integrator needing to service multiple customers, or a company that engages multiple external vendors.
Finally, if you have any questions about getting federated identity working for AAD and Visual Studio Online specifically feel free to leave a comment and I’ll help you out if I can.