As organizations continue their migration to the cloud, for many this now includes their Active Directory (AD). For example, in the education space there’s been a recent push by Microsoft for school districts utilizing Office 365 to adopt Microsoft InTune, a mobile device management platform for K12 education. However, InTune only works with Microsoft Azure AD, thus, requiring a shift from an on-premise AD model to SaaS-based Microsoft Azure AD.
With any shift to the cloud, questions may be raised surrounding loss of localized control and security— and a move to SaaS-based AD is no different. After all, organizations use AD as their central "hub" of identities, connecting their applications into it to use AD security groups and to manage role-based access to applications through AD.
If your organization is making this move or even considering it, you may be wondering how this will affect your identity management and access controls. Furthermore, can your existing Identity and Access Management (IAM) solution even integrate with Azure AD?
These are important questions to ask. IAM solutions aren’t created equal; not all offer the ability to integrate with Azure AD, and even if your solution does, it might not be capable of the end-to-end identity and access management you need. However, some IAM solutions offer the ability to integrate with Azure without losing any of this functionality.
Let’s take a look at the capabilities your IAM solution should support if you’re switching to or using Azure AD, and why they’re so critical.
For starters, it’s critical that your solution can manage the full identity lifecycle of users across your organization’s hybrid on-premises and cloud environment. This includes not only the ability to provision, manage, and deprovision Azure AD accounts, but also providing a complete audit trail of this. For IAM solutions that integrate with Azure AD, this is typically where the capabilities end.
The move to Azure AD shouldn’t negatively impact user experience. While some solutions can provision and manage Azure AD accounts, authenticating users logging into devices that are joined to an Azure AD network using federation is another story.
Federation is a specific type of single sign-on (SSO) that enables organizations to integrate with applications without exposing critical systems or data by leveraging a trusted party to identify and authenticate constituents. The trust has been established between the systems ahead of time to verify this mutual exchange of information.
To enable authentication via federation with Azure AD, WS-Federation and WS-Trust protocols must be used, so it’s critical that your IAM solution supports these protocols.
Access controls help enforce the principle of least privilege by ensuring users have the right access, to the right resources— both on-premises and cloud-based— for the right amount of time— and nothing more. While there are a number of access control methods, including Attribute-Based Access Control (ABAC) and Entitlement-Based Access Control, many IAM solutions only support Role-Based Access Control with Azure AD. However, role-based access control alone isn’t granular enough to meet all of an organization’s access needs or to enforce least privilege access.
Digging a little deeper, let’s explore the differences between these methods and why using a combination of methods enables more granularity with access controls.
Role-Based Access Control (RBAC) is a method that grants access rights to users depending on their assigned “roles.” A role can be a job function or it can be a grouping based on similar data attributes. Assigning a role to a user grants that user access to a particular set of applications. These access rights are known as entitlements.
For example, a user with the role of“nurse” would have access to particular modules or functions in an Electronic Medical Record (EMR). On the other hand, a physician’s role would grant that user different levels of access within the EMR, such as the ability to generate prescriptions.
RBAC is good for making access control decisions with broad strokes. For example, giving all teachers access to Google or all contractors access to email. However, many times, more granularity than this is needed or decisions need to be made under certain conditions. For these instances, there’s ABAC.
Attribute-Based Access Control (ABAC) offers organizations additional layers of granularity when granting users access rights. This method uses policies that combine attributes together, including user information, the specific resource or application, and environmental factors, such as time or location.
Instead of randomly assigning static permissions as with RBAC, permissions can be conditional. For example, having the job title of “Nurse” or “Doctor” gives a user initial access to an EMR system. However, having a department indicator, like “Radiology” would also give the user access to radiology applications.
Entitlement-Based Access Control (EBAC) is a method that grants access rights to users not only for resources or applications, but further, fine-grained functionality depending on entitlements. For example, if a user is granted the “EMR System” entitlement, they get basic access when they log into the EMR. However, if they also hold the “Electronic Prescribing” entitlement, they can prescribe medication through the EMR. Ultimately, entitlements are usually received through a birthright based on provisioning rules (certain job or role) and can be driven by both RBAC and ABAC.
Innovative IAM solution providers and security-conscious organizations are looking forward to the horizon of access control methods: Risk-Based Access Control (RiBAC). RiBAC works by looking at contextual factors, as well as a user’s events and behavior to determine the access they are given. For example, if a user is logging in from Tokyo on a business trip, but their ID card is swiped at a card reader in Chicago, that would register as an anomaly and cause the user’s access to be suspended.
In order for RiBAC to work properly, organizations need to have the necessary tools in place to perform the data collection, analysis, and monitoring required to identify trends in behavioral data and determine what might be anomalous behavior. Fortunately future-focused IAM solution providers are already beginning to integrate this functionality and artificial intelligence capabilities into their solutions.
Access controls and the tools that enable and integrate with them are constantly evolving. Microsoft’s Azure AD is just the latest example of newer, cloud-based offerings that can cause organizations to evaluate their current infrastructure and access controls.
To keep pace with this level of change, your organization needs to be able to rely on an IAM solution that seamlessly enables cloud services without sacrificing any level of identity management or security controls.
While some vendors may say that they enable end-to-end IAM in the cloud, often they are really just offering user lifecycle management without authentication capabilities or granular access controls. This is why it is vital to both user productivity and the security of your organization to utilize a future-focused IAM solution that can meet your needs of today and tomorrow.