Why the Business is requesting B2B Federation from Azure AD to Centrify Privilege Service

Why the Business is requesting B2B Federation from Azure AD to Centrify Privilege Service

This article introduces the concept of B2B federation from Azure AD to Centrify Privilege Service and explains why some businesses are choosing this form of federation to drive access to Centrify Privilege Service.

Part II explains the basic "How To" steps to set this up with Microsoft Azure and Centrify Privilege Service.

The Centrify platform provides core security services for customers including Privileged Identity Management (PIM) and Multifactor Authentication (MFA). These services are critical to securing sensitive accounts and access on infrastructure systems. I have also found that more and more customers want their administrators using their existing single sign on solution to federate into the Centrify administration console (instead of having Centrify handle the login authentication). Many organizations prefer to separate authentication from authorization, they want to standardize on one authentication source (or identity provider), and they don’t want to put all their vendor/contractors in their enterprise directory (usually Active Directory). They want their enterprise single sign on solution to manage authentication (including MFA) and only allow access to the PIM solution through Federation. Then they can manage the authorization separately in the PIM solution (Centrify in this case) as needed. It’s a great practice for environments where there is a diverse set of IT admins needing access to the PIM solution. The good news is that Centrify can already do this because federation capabilities are built into the platform.

Let’s discuss a specific scenario to highlight the use case. An organization’s infrastructure team has 1000s of servers on premise that are managed by a combination of employee administrators and 3rd party vendors/contractors. The organization wants to use a PIM solution to manage privileged access and control the authorization within the PIM solution. However, they don’t want the PIM solution to be responsible for authenticating the user. The authentication (via SAML) will come from their enterprise SSO solution.

I ran into this exact scenario with a customer that had standardized on Microsoft Azure Active Directory as their Identity Provider. The business reason for this customer was that they didn’t want to provision accounts for 3rd party vendors and contractors in their local identity repository (Active Directory) or allow them to access the network using VPN. The effort of managing these 3rd party vendor accounts and the subsequent paperwork was taking them enormous amount of overhead and time to manage.

Conceptually, the steps that the organization wanted for access to the PIM solution was as follows:

Instead of creating another account within Centrify or within your Active Directory for the contractor, the contractor signs into Centrify with their existing account in Azure (via federation) and Azure can enforce MFA.

After authenticating in Azure, the contractor is redirected to the Centrify PIM application and authenticated with his federated identity. The organization’s Centrify administrators can control what the contractor sees and can manage based on the Application or business area that they are contracted to work on.

Centrify provides B2B federation out of the box so we were able to set this up. Here’s what it looks like in action using SP initiated federation with Centrify as the SP and Azure as the IDP:

Step 1: The contractor navigates to your Centrify Service and signs in with his Azure account.

Step 2: The contractor is redirected to log in to their Azure portal.

Step 3: The Azure portal authenticates the contractor accordingly. This is where you can enforce MFA through Azure if that is a requirement.

Step 4: The contractor will then be logged into Centrify where they can manage the back-end systems, secrets, and vaulted accounts that they need to use to access the specific application they are contracted to manage.

As you can see, the contractor does not need a new identity, and can sign in with his existing identity in Microsoft Azure. The business benefit is that the organization does not need to manage the contractor’s identity separately for Centrify and doesn’t need to provide VPN access. The infrastructure team can leverage the existing authentication process through Microsoft Azure and focus on controlling authorization to specific resources within Centrify.

Organizations can take this one step further by also configuring attribute-based authorization. What this means is that we can map an authorization role in Centrify to a Group attribute that is sent over by Microsoft Azure. When the federation token passes in a specific Group Attribute, Centrify will place the user in a mapped Centrify Role that will automatically grant them access to only what that Role is allowed to manage. Pretty slick.

In part II of this blog, I cover the step by step setup with Microsoft Azure acting as the IdP. An example of how you can federate from a Centrify IdP to a Centrify SP can be found here.