Evaluating common integrations between Azure AD and APM - Part 1

Identity as a Service providers (IDaaS) are exploding in adoption rate, Azure AD being one that I encounter most frequently. Given that, I am often asked what options are available for integration between Azure AD and BIG-IP APM, including implementation steps. In this 4-part series, I will first summarize and contrast the integration options, including the pros and cons of each, then in each subsequent article we will dive into the requirements and implementation details for each method of integration. Please note that there may be additional integrations and authentication flows, this article series is however only covering 3 in particular.

The 3 authentication flows we will discuss in this article series are:

1. Network Policy Server (NPS) Azure MFA extension**
2. SAML federation
3. ROPC Oauth grant authentication flow

**This replaces the legacy integration with Azure MFA Server which is no longer supported: https://devcentral.f5.com/s/articles/heres-how-i-did-it-integrating-azure-mfa-with-the-big-ip-19634

Method 1: Azure NPS Extension

The method we will be examining in the first article of this series is integration between BIG-IP APM and Azure AD via a Network Policy Server (NPS) extension. This method is used to achieve Azure AD Multi-factor Authentication (MFA) capabilities for user authentication which is most often the primary business requirement for integration. 

User authentication requests are sent from BIG-IP APM to the NPS server where the NPS extension for Azure MFA will then inform Azure AD to initiate the MFA challenge. The NPS extension for Azure MFA does NOT support any conditional access policies, as the source of every authentication request from Azure AD's perspective will be that of the NPS server itself. By using this method, we can capture the username and password on the APM logon page for seamless password-based Single Sign-On (SSO), plus we get the MFA capabilities of Azure AD, truly the best of both worlds.

Architecture and authentication flow:

 

1. User requests a resource protected by BIG-IP APM and is presented with an APM logon page where they enter their credentials.
2. BIG-IP captures these credentials as session variables and sends them to the predefined RADIUS AAA server, in this case that would be the NPS server with Azure MFA extension.
3. The RADIUS server first validates user credentials, if successful then the 'AzureMFA' extension will notify Azure AD of the incoming user authentication request and initiate MFA challenge.
4. The user is challenged using the chosen MFA method.
5. Azure AD notifies the NPS extension of the MFA challenge result.
6. The NPS extension responds back to the BIG-IP with a RADIUS response based on the outcome of the MFA challenge.
7. If successful, the user is granted access to the protected application, webtop or resource.

Pros:

• BIG-IP APM can capture both the username and password as session variables as part of the logon process, making password-based Single Sign-on (SSO) viable
• Requires no federation between BIG-IP and Azure AD

Cons:

• Requires external infrastructure dependencies (Redundant NPS infrastructure)
• Azure AD Conditional access policy support is limited ***This however can be augmented with conditional policies on BIG-IP APM

Method 2: SAML federation with Azure AD

SAML is a well understood and adopted standard for federation between identity domains. By federating BIG-IP APM with Azure AD as the Identity Provider (IDP) we direct all user authentication requests to Azure AD. This means that all authentication features supported by Azure AD, such as Conditional Access Policies and MFA will work as intended, as the user is interfacing directly with Azure AD during authentication. By its very design, SAML federation limits the SAML Service Provider (SP), which is the role of BIG-IP APM in this case, from receiving the user's password as part of the authentication flow; this means we must use passwordless Single Sign-On (SSO) methods such as Kerberos or SAML for seamless access to applications and resources.

Architecture and authentication flow:

 

**Above depicts SP-initiated SAML authentication flow where BIG-IP APM is the Service Provider (SP) and Azure AD is the (IDP)

1. User requests a resource protected by BIG-IP APM. 
2. APM responds to the user with a SAML request and directs them to the IDP (Azure AD).
3. The user browser relays the SAML request to Azure AD. It is at this point that the user authenticates DIRECTLY with Azure AD.
4. Once successfully authenticated (including MFA, if applicable), Azure AD responds to the user with a SAML response containing an Assertion and directs the user back to the BIG-IP APM.
5. The user browser relays the SAML response to the BIG-IP and is provided access to the protected application or resource.

Pros:

• Widely deployed and understood + very easy implementation
• Full support for conditional access policies and authentication functionality in Azure AD

Cons:

• BIG-IP APM will not receive a password as part of the logon process - this means that password-based Single Sign-On (SSO) will not work out of the box ***We will explore options to get around this further in Article #3

Method 3: ROPC Oauth Grant

The Resource Owner Password Credentials (ROPC) grant allows an application or intermediary to sign a user in by directly handling their password. Put simply, BIG-IP APM first captures the user credentials with a standard logon page and then validates them with Azure AD directly. This authentication flow may resemble that of traditional authentication flows such as Active Directory domain controllers or RADIUS servers. In most cases, ROPC grant flows are not highly recommended, as the user credentials are provided to the Oauth 2.0 client (BIG-IP) directly instead of to the Authorization Server (Azure AD) which arguably introduces additional risk. By using this method however, we capture the username and password on the APM logon page for password-based Single Sign-On (SSO) without requiring any on-premises infrastructure such as domain controllers or AAA servers to handle authentication.

Architecture and authentication flow:

 

1. User requests a resource protected by BIG-IP APM and is presented with an APM logon page where credentials are input.
2. BIG-IP captures these credentials as session variables and sends them to the predefined Oauth Authorization Server (AS), Azure AD.
3. If the credentials are correct, Azure AD responds to the BIG-IP with an ID token, Access token and optionally a refresh token.
4. If successful, the user is granted access to the protected application or resource.

Pros:

• BIG-IP APM can capture both the username and password as session variables as part of the logon process, making password-based Single Sign-on (SSO) viable
• Requires no on-premises infrastructure such as Active Directory or RADIUS/NPS for authentication

Cons:

• Not recommended by Microsoft for Security reasons.
• No direct support for Azure AD MFA
• No support for Azure AD conditional access policies ***This however can be augmented with conditional policies on BIG-IP APM

Summary 

In the first article of this series we reviewed 3 unique options for integration between BIG-IP APM and Azure AD. We also described the authentication flow as well as the pros and cons for each method. In each subsequent article, we will dive deeper into these three methods, providing detailed implementation instructions, caveats, and requirements as well as some anecdotal wisdom from the field!