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: Network Policy Server (NPS) Azure MFA extension** SAML federation 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: User requests a resource protected by BIG-IP APM and is presented with an APM logon page where they enter their credentials. 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. 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. The user is challenged using the chosen MFA method. Azure AD notifies the NPS extension of the MFA challenge result. The NPS extension responds back to the BIG-IP with a RADIUS response based on the outcome of the MFA challenge. 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) User requests a resource protected by BIG-IP APM. APM responds to the user with a SAML request and directs them to the IDP (Azure AD). The user browser relays the SAML request to Azure AD. It is at this point that the user authenticates DIRECTLY with Azure AD. 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. 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: User requests a resource protected by BIG-IP APM and is presented with an APM logon page where credentials are input. BIG-IP captures these credentials as session variables and sends them to the predefined Oauth Authorization Server (AS), Azure AD. If the credentials are correct, Azure AD responds to the BIG-IP with an ID token, Access token and optionally a refresh token. 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!
Azure Active Directory and BIG-IP APM Integration
Introduction Security is one of the primary considerations for organizations in determining whether or not to migrate applications to the public cloud. The problem for organizations with applications in the cloud, in a data center, managed, or as a service, is to create a cost-effective hybrid architecture that produces secure application access and a great experience that allows users to access apps easily, have consistent user experiences, and enjoy easy access with single-sign-on (SSO) tied to a central identity and authentication strategy. Some applications are not favorable to modernization. There are applications that are not suited for, or incapable of, cloud migration. Many on-premises apps do not support modern authentication and authorization, including standards and protocols such as SAML, OAuth, or OpenID Connect (OIDC). An organization may not have the staff talent or time to perform application modernization for their on-premises apps. With thousands of apps in use daily, hosted in all or any combination of these locations, how can organizations ensure secure, appropriate user access without requiring users to login in multiple times? In addition, how can organizations terminate user access to each application without having to access each app individually? By deploying Microsoft Azure Active Directory, Microsoft’s comprehensive cloud-based identity platform, along with F5’s trusted application access solution, Access Policy Manager (APM), organizations are able to federate user identity, authentication, and authorization and bridge the identity gap between cloud-based (IaaS), SaaS, and on-premises applications. Figure 1Secure hybrid application access This guide discusses the following use cases: ·Users use single sign-on to access applications requires Kerberos-based authentication. ·Users use single sign-on to access applications requires header-based authentication. Microsoft Azure Active Directory and F5 BIG-IP APM Design For organizations with a high security demand with low risk tolerance, the need to keep all aspects of user authentication on premise is required. The Microsoft Azure Active Directory and F5 BIG-IP APM solution integrates directly into AAD configured to work cooperatively with an existing Kerberos based, header based or variety of authentication methods. The solution has these components: •BIG-IP Access Policy Manager (APM) •Microsoft Domain Controller/ Active Directory (AD) •Microsoft Azure Active Directory (AAD) •Application (Kerberos-/header-based authentication) Figure 2APM bridge SAML to Kerberos/header authentication components Figure 3APM bridge SAML to Kerberos authentication process flow Deploying Azure Active Directory and BIG-IP APM integration The joint Microsoft and F5 solution allow legacy applications incapable of supporting modern authentication and authorization to interoperate with Azure Active Directory. Even if an app doesn’t support SAML, and only is able to support header- or Kerberos-based authentication, it can still be enabled with single sign-on (SSO) and support multi-factor authentication (MFA) through the F5 APM and Azure Active Directory combination. Azure Active Directory as an IDaaS delivers a trusted root of identity to APM creating a bridge between modern and legacy applications, delivering SSO and securing the app with MFA. Adding F5 from the gallery To configure the integration of BIG-IP APM into Azure AD, you need to add F5 from the gallery to your list of managed SaaS apps. Sign-on to theAzure portalusing either a work or school account, or a personal Microsoft account. On the left navigation pane, select theAzure Active Directoryservice. Navigate toEnterprise Applicationsand then selectAll Applications. To add new application, selectNew application. In theAdd from the gallerysection, typeF5in the search box. SelectF5from results panel and then add the app. Wait a few seconds while the app is added to your tenant. Configuring Microsoft Azure Active Directory Configure and test Azure AD SSO with F5 using a test user calledA.Vandelay. For SSO to work, you need to establish a link relationship between an Azure AD user and the related user in F5. To configure and test Azure AD SSO with F5, complete the following building blocks: Configure Azure AD SSO - to enable your users to use this feature. Create an Azure AD test user - to test Azure AD single sign-on with A.Vandelay. Assign the Azure AD test user - to enable A.Vandelay to use Azure AD single sign-on. Configure Azure AD SSO Follow these steps to enable Azure AD SSO in the Azure portal. In theAzure portal, on theF5application integration page, find theManagesection and selectsingle sign-on. On theSelect a single sign-on methodpage, selectSAML. On theSet up single sign-on with SAMLpage, click the edit/pen icon forBasic SAML Configurationto edit the settings. On theBasic SAML Configurationsection, if you wish to configure the application inIDPinitiated mode, enter the values for the following fields: In theIdentifiertext box, type a URL using the following pattern:https://<YourCustomFQDN>.f5.com/ In theReply URLtext box, type a URL using the following pattern:https://<YourCustomFQDN>.f5.com/ ClickSet additional URLsand perform the following step if you wish to configure the application inSPinitiated mode: In theSign-on URLtext box, type a URL using the following pattern:https://<YourCustomFQDN>.f5.com/ Note These values are for only used for illustration. Replace these them with the actual Identifier, Reply URL and Sign-on URL. Refer to the patterns shown in theBasic SAML Configurationsection in the Azure portal. On theSet up single sign-on with SAMLpage, in theSAML Signing Certificatesection, findFederation Metadata XMLand selectDownloadto download the certificate and save it on your computer. On theSet up F5section, copy the appropriate URL(s) based on your requirement. Create an Azure AD test user In this section, you'll create a test user in the Azure portal called A.Vandelay. From the left pane in the Azure portal, selectAzure Active Directory, selectUsers, and then selectAll users. SelectNew userat the top of the screen. In theUserproperties, follow these steps: In theNamefield, enterA.Vandelay. In theUser namefield, enter the username@companydomain.extension. For example,A.Vandelay@contoso.com. Select theShow passwordcheck box, and then write down the value that's displayed in thePasswordbox. ClickCreate. Assign the Azure AD test user In this section, you'll enable A.Vandelay to use Azure single sign-on by granting access to F5. In the Azure portal, selectEnterprise Applications, and then selectAll applications. In the applications list, selectF5. In the app's overview page, find theManagesection and selectUsers and groups. SelectAdd user, then selectUsers and groupsin theAdd Assignmentdialog. In theUsers and groupsdialog, selectA.Vandelayfrom the Users list, then click theSelectbutton at the bottom of the screen. If you're expecting any role value in the SAML assertion, in theSelect Roledialog, select the appropriate role for the user from the list and then click theSelectbutton at the bottom of the screen. In theAdd Assignmentdialog, click theAssignbutton. Configure F5 BIG-IP APM Configure your on-premise applications based on the authentication type. Configure F5 single sign-on for Kerberos-based application Open your browser and access BIG-IP. You need to import the Metadata Certificate into the F5 (Kerberos) which will be used later in the setup process. Go toSystem > Certificate Management > Traffic Certificate Management >> SSL Certificate List. Click onImportof the right-hand corner. Additionally you also need anSSL Certificatefor the Hostname (Kerbapp.superdemo.live), in this example we used Wildcard Certificate. Go to –F5 BIG-IP Click Access > Guided Configuration > Federation > SAML Service Provider. Specify theEntity ID(same as what you configured on the Azure AD Application Configuration). Create a new Virtual Server, Specify theDestination Address. Choose theWild Card Certificate(orCertyou uploaded for the Application) that we uploaded earlier and theAssociated Private Key. Upload the ConfigurationMetadataand Specify a newName for SAML IDP Connectorand you will also need to specify the Federation Certificate that was uploaded earlier. Create NewBackend App Pool, specify theIP Address(s)of the Backend Application Servers. UnderSingle Sign-on Settings, chooseKerberosand SelectAdvanced Settings. The request needs to be created inuser@domain.suffix. Under theusername sourcespecifysession.saml.last.attr.name.http://schemas.xmlsoap.org/ws/2005/05/identity/claims/givenname. Refer Appendix for complete list of variables and values. Account Name Is the F5 Delegation Account Created ( Check F5 Documentation). Under Endpoint Checks Properties , click Save & Next. Under Timeout Settings, leave default settings and click Save & Next. Review Summaryand click onDeploy. Configure F5 single sign-on for Header-based application Open your browser and access BIG-IP. You need to import the Metadata Certificate into the F5 (Header Based) which will be used later in the setup process. Go toSystem > Certificate Management > Traffic Certificate Management >> SSL Certificate List. Click onImportof the right-hand corner. Additionally you also need anSSL Certificatefor the Hostname (headerapp.superdemo.live), in this example we used Wildcard Certificate. Go to –F5 (Header Based) BIG-IP Click Access > Guided Configuration > Federation > SAML Service Provider. Specify theEntity ID(same as what you configured on the Azure AD Application Configuration). Create a new Virtual Server, Specify theDestination Address,Redirect Portis Optional. Choose theWild Card Certificate(orCertyou uploaded for the Application) that we uploaded earlier and theAssociated Private Key. Upload the ConfigurationMetadataand Specify a newName for SAML IDP Connectorand you will also need to specify the Federation Certificate that was uploaded earlier. Create NewBackend App Pool, specify theIP Address(s)of the Backend Application Servers. Under Single Sign-on, ChooseHTTP header-based. You can add other Headers based on your application. See the Appendix for the list of SAMLSession Variables. Under Endpoint Checks Properties , click Save & Next. Under Timeout Settings, leave default settings and click Save & Next. Review Summaryand click onDeploy. Resources BIG-IP Knowledge Center BIG-IP APM Knowledge Center Configuring Single Sign-On with Access Policy Manager Summary By centralizing access to all your applications, you can manage them more securely. Through the F5 BIG-IP APM and Azure AD integration, you can centralize and use single sign-on (SSO) and multi-factor authentication for on-premise applications. Validated Products and Versions Product BIG-IP APM Version 15.0
Yubikey Authentication Modes and Azure AD integration via the APM
Introduction The Yubikey (https://www.yubico.com/) supports three major functions, authentication, signing and encryption. As far as authentication goes, it supports a list of the following mechanisms. OTP (one-time password) Yubikey OTP (Time based OTP) OATH HOTP (HMAC based OTP) FIDO U2F (Universal 2 nd Factor) FIDO2 PIV (Smartcard) Each of the above-mentioned protocols has its own set of requirements and is therefore not universally supported everywhere. OTP OTP is probably the simplest, with a one-time password being used, typically as the 2 nd factor. However, it is also the weakest, as it does not mitigate against MITM attacks. E.g., A fake site impersonating a legitimate site can trick the user into entering the OTP and subsequently forwards it to the real site. All Yubikey’s by default have manufacture assigned secrets registered with Yubico’s own validation servers. Yubico provides a tool that allows you to re-program the key, giving it a different secret. However, the new secret has to be uploaded to Yubico’s validation servers (https://upload.yubico.com/) otherwise OTP will stop working. Yubikey OTP integrates with a large number of services (e.g., Gmail, LastPass). When a service receives an OTP, it reaches out to Yubico for validation. In the case of Okta, the secrets can be uploaded directly into Okta and validation happens within Okta. FIDO U2F FIDO U2F or U2F for short, mitigates MITM. This method requires the user to register the authenticator (e.g., Yubikey) with the application (e.g., Gmail) first, during which a key pair is generated by the authenticator, and the public key is sent and stored on the application. Once the registration is complete, the user can then use the authenticator as the 2 nd factor. In the case of Gmail, once the user’s credentials are verified, the user touches the Yubikey for 2 nd factor. No code is entered by the user. FIDO2 FIDO2 enables passwordless authentication. Once the Yubikey is registered with an application (e.g., Azure Portal) for FIDO2 authentication, the user touches the Yubikey, optionally provides a PIN code for the key, logs straight in. – no username is entered FIDO2 is an evolution of U2F and is dependent upon WebAuthn (client API implemented within the browser) and CTAP2 (authenticator API that enables FIDO2-capable devices to interface to external/roaming authenticators over Bluetooth, USB or Near field communication (NFC)). Per FIDO Alliance (https://fidoalliance.org/fido2/fido2-web-authentication-webauthn/#:~:text=WebAuthn%20is%20currently%20supported%20in,Windows%2010%20and%20Android%20platforms), browser support for U2F and WebAuthn are shown below. PIV YubiKey can also present itself as a PIV smartcard that contains a client certificate. APM Integration There are a number of articles on DevCentral that cover programming the APM to receive the Yubikey OTP and then send it over to Yubico’s validation servers via a side band connection for OTP verification. My particular use case is to leverage an IDaaS (e.g., Azure AD) as an IDP and use the APM as the SP. My choice of integration is via OIDC, but SAML is an equally valid option. Since authentication is offloaded to Azure AD, both the OTP and FIDO2 passwordless authentication methods are now available. Azure AD does not support U2F. Azure AD and User Configuration OTP If Yubikey is used for OTP, Azure AD needs to have MFA enabled, a ‘Conditional Access’ policy is created to ‘Require multi-factor authentication’ for your selected apps. This process is documented by Microsoft (https://docs.microsoft.com/en-us/azure/active-directory/authentication/tutorial-enable-azure-mfa). The user must also add an authenticator app via self-registration (https://mysignins.microsoft.com/), be sure to click on the highlighted, this allows you to enrol the ‘Yubico Authenticator’ (https://www.yubico.com/products/services-software/download/yubico-authenticator/). The Yubico Authenticator works with the Yubikey to generate the OTP. Yubico argues that it is more secure as unlike a soft authenticator, the secrets are not saved within the authenticator itself, but rather in a secure element within the Yubikey. Note ‘Touch your Yubikey’, which is needed before an OTP is generated. The OTP method does not impose special requirements on the browsers, which means it works on any browsers, as well as on the APM Edge client, which leverages certain browser functions FIDO2 With FIDO2 based passwordless authentication, the ‘FIDO2 Security Key’ option within the Azure AD (e.g., under Security) has to be enabled first. Again, the user goes through self-registration (https://mysignins.microsoft.com/) prior to the Yubikey becoming available. I have tried different browsers on the Mac, the only browsers that work are Chrome and Edge. Milage may vary in Windows. If FIDO2 works, the highlighted option will appear. In the case of Azure AD, a PIN is required (configured over the self-registration process). Once it’s entered, the user logs in after touching the Yubikey. At this time, the latest (v7210) APM Edge client’s embedded browser for login does not work with FIDO2, likely due to WebAuthn not being supported. If the user uses a supported browser, passwordless authentication should work, after which a webtop is presented.
