How are calls to Azure management API authorized?

Question

I find the authorization flow confusing for calls to Azure's management APIs, i.e. not Azure API management which is the API gateway SaaS, and I'm hoping for some clarification.

From documentation at https://msdn.microsoft.com/en-us/library/azure/dn629581.aspx:

Although Azure originally allowed access only by Microsoft account users, it now allows access by users from both systems. This was done by having all the Azure properties trust Azure AD for authentication, having Azure AD authenticate organizational users, and by creating a federation relationship where Azure AD trusts the Microsoft account consumer identity system to authenticate consumer users. As a result, Azure AD is able to authenticate “guest” Microsoft accounts as well as “native” Azure AD accounts.

and http://blogs.technet.com/b/ad/archive/2014/08/15/prepping-for-new-management-features.aspx:

Your Microsoft Azure subscriptions uses Azure Active Directory to sign users in to the management portal and to secure access to the Azure management API.

The documentation leads me to believe the Azure AD tenant associated with a subscription acts as a STS with management API being the RP, or authorization server and resource server respectively using OAuth terminology. The tenant can also choose to trust third-party STSes, e.g. another tenant or Microsoft Account services, and thus allow for users from external identity providers access to the management API.

The blog post also writes:

Azure will soon require administrators to be registered in Azure Active Directory to be able to sign in to the Azure portal or use the Azure management API.

Disassociating an admin's account with the subscription's Azure AD tenant, irrespective if it is a "native" account to a tenant or a federated account, should in my mind revoke their access to the management APIs.

I tried validating the assumption using one my subscriptions and couldn't quite make sense of the result. Let's say the subscription has three admins:

• Service admin SA using a federated Microsoft Account
• A co-admin CA-AAD using an account "native" to the tenant trusted by the subscription
• A co-admin CA-MSA again using a federated Microsoft Account

With all three accounts registered with the tenant, any of them can manage resources belonging to the subscription as well as use an web application that in turn access the Insights API through user impersonation.

Removing CA-AAD from the tenant disallowed the account from managing resources and accessing the Insights API once the cookie/access token had expired. This is the expected behavior, except the now non-exitant account still remains listed as a co-admin for the subscription.

However, removing CA-MSA from the tenant did not prevent the account from managing resources or accessing the API. This behavior even persisted between sessions and the account remained listed as a co-admin and not quite the expected outcome.

And now onto the questions:

• Why is CA-MSA allowed continued access to management APIs despite it not registered with the tenant?
• What is the authorization flow for accessing the management APIs?
• How are accounts mapped to those listed as co-admins for a subscription?

Answer 1

Azure subscription refers only two directories for authorizing the users for accessing the management API.

1. the Azure AD to which the subscription is associated to.
2. Microsoft AD(MSA).

When a user with Microsoft Account is added as a subscription co-admin, user is indirectly registered in the Azure AD to which the current subscription is associated to. If the user is deleted from Azure AD, it still has the subscription access. It is because the user is still present in Microsoft Account AD.