Access Control using Azure Active Directory

By adopting more and more different cloud applications in your organization the need for management and controls becomes crucial. Azure Active Directory in this case offers a wide set of features to support these scenarios. Some of the primary functionalities like account management, Multi-Factor Authentication and Federation support covers most of the needs on the authentication level and these are common practice nowadays. When it comes to controlling and granting access to applications or managing authorization in a cloud scenario and integrating with your environment, it suddenly starts to be a little bit blurry. This post will give a brief overview of the Azure Active Directory key Access Control features and it will provide a practice to combine these features which will help IT organizations to manage and service their organization in an efficient and compliant way.

Coming along with the Azure Active Directory you will be able to make use of the following fundamental features when it comes to Access Control:

  • Conditional Access;
  • Groups;
  • Roles;

Keep in mind some of these features require an Azure Active Directory Premium license. Besides, a single blog post can be written for each of the topics listed above. In this post I will address the key functionality of each of these features.

Access and Authorization

The concepts Access and Authorization are often (mis)used in the same sentence. However, in the terms of Identity of Access Management it needs to be addressed there is a significant difference. Access only ensures what a user can access based on his role within the organization. Management of these roles are often sourced from an HR system and provisioned to the different IAM sources in the IT landscape. For instance, the old school Active Directory. Authorization is the process of the granting permission on a specific functionality or resource in for example an application. This process is in most scenarios handled by the application itself using related attributes of the user. These details are stored (and managed) in the application database or provided in the incoming token / ticket based on central IAM system.

In cloud scenarios these concepts (obviously) are still required to grant users access to different applications and resources. However, by using more and more third party SaaS applications and cloud resources hosted at different vendors across the globe, it becomes key to manage Access and Authorization more centralized instead of leaving it up to the application. This results in a different way of controlling access and providing authorization to a cloud resource. This can be achieved using Azure Active Directory:



Access Control

Access control changed when applications and other functionality moved towards the Cloud. In most scenarios users make use of these services from any location and usually via the internet. This makes it simply not possible to protect services using a dedicated whitelist of IP’s to control access to your services like we did in the old days. Again, the identity of the user is the key solution in this scenario. Azure Active Directory Conditional Access offers the ability to allow or deny access based on defined conditions. This condition might be based on the source IP address of the user or an Azure Active Directory group. The policy defined in the access rule defines if the user needs to login using an extra authentication factor to prove his identity. This enables one centralized approach by using this access rules for all your enterprise Cloud applications.


In addition to the use of Conditional Access, it is considered a common practice to control access to applications using Azure Active Directory groups. The membership of an application group defines if you may access the application. Management of these memberships is either based on attributes of the identity using Dynamic Memberships or sourced from the on-premises environment using Azure AD Connect.


Where Access Control covers the question: Who can, based on his identity, access what applications or services? Authorization defines the mechanism and permissions on a granular application level. Instead of leaving the authorization up to the application itself, it is now required to manage this centralized. Meaning, you should make use of the “Authorization calls” and/or the “Claims” offered in the authentication token, to let the application decide whether the user is permitted to make use of certain functionality within an application. An Authorization call is a verification request which is send to the authorization provider at the moment the user tries to access a certain functionality or resource. In Azure Active Directory the Graph API can be used to check the user’s membership or role defined. As mentioned, claims in the authentication token can also be used to do the authorization, meaning the membership or role is send as a claim. Both options take away the need of provisioning identity related information to the different Cloud applications which isolates the identity related information from the application specific data.

So what will use for authorization: Groups or Roles? Azure Active Directory offers both, but what is the difference? Azure Active Directory groups can be created on a tenant level meaning the groups can be used for all applications related to the tenant. Roles, however, are configured on per application basis. Is this directly a con? In my opinion it is not, application roles should only be related to one specific application as this defines the role and thus permissions you have in this particular application. Another differentiator is the way you can maintain the memberships to this roles and groups. Azure Active Directory groups are easily integrated in enterprise scenarios as most are using the Active Directory groups already which can be synchronised to Azure Active Directory very easily. Roles, on the other hand, are based on the assignments at an Azure Active Directory level without the option to synchronize this from any on-premises environment. Groups, however, do have some cons as well. For instance, there is a limit to groups that you can get in the authentication token.

To work towards to ultimate authorization model, you should make use of the best of both worlds. Assign your users to groups and assign your groups to the application roles:


See this blog post for more information about how to integrate this with your application.

Bringing it all together

Azure Active Directory offers a lot more features which are not all addressed in this post. Especially from an end-user and management perspective services like the portal and the Identity Protection service should be added to offer an end-to-end solution.

If you want to know more about this or the access and authorization services covered in this post, come join me and Annejan Barelds during our session at Dutch TechDays 2016. See you there!