This tutorial guide guides you through the processes required to successfully integrate the EdgeADC with Azure Active Directory, particularly SAML-based authentication, and Single Sign-On.

Once integrated, the combination of Azure AD and EdgeADC will provide:

  • The ability to control which users can access applications sitting behind the EdgeADC virtual services using Azure AD
  • Provide Single Sign-On for users listed in your Azure AD
  • Manage all your application-access user accounts centrally in the Azure portal

In this article

Benefits

Prerequisites

Scenario Description

Configuring Azure AD Single Sign-On

How to test the configuration

Configuring the EdgeADC for Azure AD SAML Authentication

Creating the SAML Profile on EdgeADC

Testing the SAML Definition

Configuring the EdgeADC for Kerberos Authentication

Configuring Kerberos On EdgeADC

Redirecting Users to Kerberos Authentication

Testing the Implementation

Benefits

Other benefits include:

Prerequisites

In order to make full use of this feature, you will need to ensure that you meet the following criteria:

  • You have a current and valid Azure ADC subscription
  • An Edgenexus Azure AD integration single sign-on (SSO) enabled subscription
  • An Edgenexus EdgeADC that has been updated to the latest version incorporating the Azure AD SAML and Kerberos integration

Scenario Description

Older applications, often called legacy, do not incorporate modern protocols, making direct integration with Azure AD challenging. Although it’s feasible to update the application, this process is expensive, necessitates meticulous planning, and brings with it the risk of possible service interruption.

As an alternative, an Edgenexus EdgeADC Application Delivery Controller (ADC) is deployed to act as an intermediary between the antiquated application and the contemporary ID control plane by facilitating protocol transitioning.

Positioning an EdgeADC ahead of the application allows us to enhance the service by incorporating Azure AD pre-authentication and headers-based Single Sign-On (SSO). This substantially boosts the application’s overall security stance.

The following solution architecture applies in this example.

The User Application

The user application sits on Real Servers and is protected by the EdgeADC.

Azure Active Directory

The Security Assertion Markup Language (SAML) Identity Provider (IdP) is in charge of validating user credentials, implementing Conditional Access (CA), and facilitating SAML-based Single Sign-On (SSO) for the EdgeADC. Azure AD supplies the EdgeADC with any necessary session attributes through SSO.

EdgeADC

The EdgeADC is a high-end application load balancer. It acts as a reverse proxy and SAML service provider (SP) for the application, delegating the authentication process to the SAML IdP prior to executing header-based Single Sign-On (SSO) to the backend application.

SAML Authentication Flow

Description of Flow Elements

  1. The user requests access to the application on the Real Server by accessing the SAML-protected Virtual Service
  2. The EdgeADC generates a SAML request
  3. The EdgeADC redirects the user-initiated request to the SSO URL and returns it to the client browser
  4. The client browser then sends the redirected request to the IdP for authorization to be initiated. A web page is displayed on the client browser requesting credential input
  5. Once the credentials have been submitted, the IdP scans the SAML Request and uses the credentials provided to authenticate the user against the data held in Azure AD.
  6. The IdP then generates the required SAML Response in readiness to send
  7. The IdP then encodes the SAM Response and sends it back to the client browser
  8. The Client browser then performs a POST action to the EdgeADC that includes the SAML Response
  9. The SAML Response is processed and validated on the EdgeADC, which then either grants or denies access to the user application. KCD processing is performed on the EdgeADC if KCD has been enabled
  10. If the EdgeADC validates the SAML Response positively and grants access, the user is then provided access to the user application on the Real Servers
  11. The user then continues to use the application
  12. Once the user has finished with the application, they log off
  13. The Log Off Request is sent from the client to the EdgeADC for SAML action
  14. The EdgeADC sends a redirect to the Log Off URL to the client browser
  15. The client browser sends the SAML Log Off Request to the IdP
  16. A SAML Log Off response is sent by the IdP to the EdgeADC via the client browser, concluding the process

Configuring Azure AD Single Sign-On

In order to enable the processing of SAML authentication, you will need to enable Azure SSO within your Azure portal.

In order to configure the SSO correctly, please follow the steps below:

  1. The Edgenexus EdgeADC Azure AD Integration application is within the Azure portal. Within this, locate the Manage section and select Single Sign-On.
  2. You will now see the Select Single Sign-On page that will show a number of options. Select the SAML option to begin the process.
  3. You will be taken to the Setup Single Sign-On with SAML page which contains a number of sections. These sections contain the information you need to set up the EdgeADC side. An example of this page is shown below.
  • Click the Pen icon to edit this page so that you can enter your details.
  • In the Identity Identifier (Entity ID) field, enter your identifier URL:
    https://{YOUR-DOMAIN-NAME}.{DOMAIN-NAME}
    for example https://crm.gonzo.com
  • In the Reply URL (Assertion Consumer Service URL) field, enter the Reply URL:
    https://{YOUR-DOMAIN-NAME}.{DOMAIN-NAME}
    for example https://crm.gonzo.com

You should note that the above values are not the actual ones to use. The actual values are available on your portal. If you have any questions, please refer to Edgenexus Support.

  • Further down the page, you will find a SAML Signing Certificate section. You will need to download the following items using the links located in this section:
    • Certificate (Base 64) – this will need to be imported into the EdgeADC as described elsewhere in this guide.
    • Federation Metadata XML
  • Within the Setup Edgenexus EdgeADC Integration section, copy the URLs pertinent to your requirements. You will need to enter these into the EdgeADC SAML Authentication configuration.

How to test the configuration

You will need to ensure that the Azure SAML configuration you created works. Follow the steps below:

  1. In the left pane of the Azure Portal, first select Azure Active Directory followed by Users, then All Users.
  2. Select New User – located at the top of the screen
  3. Fill out the fields to define the properties for the new user.
    1. Name: SAML TEST
    1. User Name: [email protected] (for example, [email protected])
    1. A password is automatically created, and you must write down this password to ensure you can test. Select the Show Password checkbox, and make a note of it
    1. Click the Create button

Assigning the Test User

In order to enable testing this user, they must first be granted access to the Edgenexus EdgeADC Azure AD Integration. Follow the steps below.

  1. Select the Enterprise Applications option in the left panel of the Azure Portal, and then select All Applications.
  2. In the Applications list, select Edgenexus EdgeADC Azure AD Integration
  3. In the Overview page, locate the Manage section, and select Users and Groups
  4. Now, select Add User, then Users and Groups in the Add Assignment dialog
  5. Next, in the Users and Groups dialog, select the SAML TEST user from the list displayed. This is the user you created earlier for testing the SAM configuration. Click the select button located at the bottom of the page
  6. There may be cases where you must assign a Role to the user. You can select the appropriate Role from the Select a Role dropdown. Otherwise, the Default Role is applied.
  7. In the Add Assignment dialog, you must now click the Assign button to finalize this process.

Configuring the EdgeADC for Azure AD SAML Authentication

In order to successfully utilize the Azure AD SAML technology to allow the user access to applications, you must first configure the EdgeADC. This section of the tutorial will take you through the steps from start to finish.

Creating the Virtual Service

  1. Log on to the EdgeADC and navigate to IP Services
  2. On the right panel, and in the Virtual Services section, click the Add Service
  3. You will be presented with fields that require filling in, representing the settings for creating the virtual service.

    Fill out the fields for IP Address, Subnet Mask, Port, and Service Type as shown in the image. Note that these are only examples.
  4. You may have noticed that the Real Servers section below Virtual Services has changed, and you are now being asked to enter the details of the first Real Server hosting your application. Enter the details for the first of the Real Servers. This can be an IP Address or a valid hostname. An example is shown below.
  5. Once the first server has been added, you can add more servers to the load-balanced pool by using the Copy Server button and editing the details as required.
  6. The Virtual Service and Real Servers are now created as a basic configuration. However, as shown in the image below, you will still need to specify the Load Balancing Policy and Server Monitoring method, together with the SSL configuration.

Importing SSL Certificates to the EdgeADC

For SSL communications to take place successfully, you need to install certificates into the EdgeADC that match your Internet-facing hostname and perhaps your application hostname. This process is very simple on the EdgeADC, and is outlined below.

  1. Navigate to Library > SSL Certificates using the Navigation Panel on the left of the EdgeADC screen
  2. Scroll down until you see the section labeled Import Certificate
  3. IMPORTANT: You must have your SSL certificate in PKCS #12 format, also known as PFX. If you have a PEM or CER certificate, this will be accompanied by a private key file (.key). You will need the certificate file (.pem or .cer) and the private key file to convert it to PFX. You can use OpenSSL Tools to convert your SSL certificate to a PFX format but remember to provide a password when you make the conversion.
  4. Provide a name for the certificate. This should not have any spaces.
    Provide the password you used when creating the PFX file.
    Browse for and import the certificate file.
  5. Once imported, attach the file to the Real Servers in the Virtual Service you created earlier. This has two sections: Virtual Service SSL Certificate and Real Server SSL Certificate.

    If you wish to use SSL Offload, you only need to populate the Virtual Service option. If you wish to use SSL Re-encrypt, you must populate both Virtual Service and Real Server options.

Creating the SAML Profile on EdgeADC

Importing the IdP Certificate

  1. Navigate to Library > SSL Certificates located in the Library section of the Navigation panel.
  2. Further down the right side page, you will find the Import Single Certificate section
  3. Select the type of SSL certificate you wish to import. The EdgeADC supports the following: .PFX, .CER, .DER and .PEM and private .key files where appropriate
  4. Fill in the Certificate name and other fields as appropriate
  5. Click Import
  6. The certificate is imported into the EdgeADC Certificate Store

Creating the Azure AD SAML Authentication Server and Rules

In order for the EdgeADC to perform a SAML authentication, two elements are required:

  • Authentication Server Definition
  • Authentication Rule Definition

Authentication Server Definition

The Authentication Server is defined within the Library > Authentication Server page. This can be accessed via the Navigation panel.

The following steps will help you define the Azure AD for SAML authentication.

  1. Click the Add Server button
  2. A blank line will appear in the main table, and fields underneath for you to fill in
  3. Fill out the Name field and select SAML from the Authentication Method dropdown
  4. A new set of fields will be shown below pertinent to SAML authentication
  • Fill in the fields using the information you obtain from the Azure AD SAML section
  • Click Update when done.

SAML Field Definitions

  • IdP Certificate Match: “IdP Certificate Match” refers to the process where the Service Provider (SP) checks if the digital certificate provided by the Identity Provider (IdP) during the SAML SSO process matches with the one that the SP has on record. This process ensures the authenticity and integrity of the SAML assertions.
    In simple terms, consider the “IdP Certificate Match” as a secret handshake. It’s a way for one system (the Service Provider) to confirm that it’s talking to the correct other system (the Identity Provider) and that the information it’s receiving has not been tampered with.

If the certificate provided by the IdP doesn’t match the one the SP has on record, the SAML assertion may be rejected because it’s considered untrustworthy. This process plays a critical role in enhancing security for SSO operations.

  • IdP Entity ID: The IdP Entity ID, or Identity Provider Entity ID, is a unique identifier for the Identity Provider (IdP) in a SAML Single Sign-On (SSO) process.
    In simple terms, you can think of it as a specific name that uniquely identifies the system (in this case, the Identity Provider like Azure AD) within the SSO process. This ID helps differentiate various systems or entities involved, particularly when multiple identity providers or service providers are involved.
  • IdP SSO URL: The Identity Provider Single Sign-On URL (IdP SSO URL) is the web address to which the service provider (EdgeADC) should send SAML authentication requests. When a user tries to access a service (like a web app), the EdgeADC redirects the user’s browser to this URL. The user then authenticates against this URL (managed by the identity provider, such as Azure AD). If successful, they are returned to the original service with a SAML assertion proving their authentication. Therefore, the IdP SSO URL is a crucial part of the SAML SSO flow, acting as the main point for user authentication.
  • IDP Logoff URL: The Identity Provider (IdP) Logoff URL is a specific location defined within an IdP, like Azure Active Directory, to which users are directed when they sign out. It’s part of the single sign-on (SSO) workflow, allowing the IdP to handle user sign-out requests and ensure they are securely logged out from all connected services. This provides a seamless and secure user experience as users only need to log out once from their central IdP to be logged out from all associated Service Providers (SPs).
  • IdP Certificate: The Identity Provider (IdP) Certificate, or the signing certificate, is a digital certificate used in the SAML SSO process to establish trust between the Identity Provider (like Azure AD) and the Service Provider. This certificate, which includes a public key, is shared with the Service Provider. It allows the Service Provider to verify that the SAML assertion, sent from the IdP, is legitimate and hasn’t been tampered with, ensuring the data’s integrity and authenticity. The private key corresponding to this public key is securely kept by the IdP and used to sign the SAML assertions.
  • SP Entity ID: The SP Entity ID, also known as the Service Provider Entity ID, is a unique identifier used in the SAML (Security Assertion Markup Language) process that specifically identifies the service provider in a SAML transaction. It is essentially the name by which the Identity Provider (IdP) recognizes the Service Provider (SP). This could be any unique value but often takes the form of a URL. This ID is included in SAML responses sent by the IdP so that the SP knows the response is intended for it. It’s crucial for maintaining the integrity and security of the SSO (Single Sign-On) process.
  • SP Signing Certificate: The SP (Service Provider) Signing Certificate is a digital certificate the service provider uses to sign the SAML responses or assertions it sends. By signing these messages, the Identity Provider (IdP) can verify that they came from the service provider and haven’t been tampered with during transmission. Essentially, it’s a measure to enhance the security and integrity of the SAML SSO process, helping ensure that the information being transmitted is authentic and trustworthy.
  • SP Session Timeout: SP Session Timeout refers to the duration for which a user’s session remains active on the Service Provider (SP) side after successful authentication via Single Sign-On (SSO). It defines the period during which the user can interact with the service without needing to re-authenticate. Once the session expires, if the user continues to interact with the service, they must re-authenticate, usually by being redirected to the Identity Provider (IdP). This setting is essential for managing security and user experience.

Creating the Authentication Rule

In order for users to be correctly redirected to SAML authentication, you need an Authentication Rule in addition to the Authentication Server.

To create an Authentication Rule, follow the steps below:

  1. Click the Add Rule button
  2. This will create a new, blank entry in the table
  3. In the Name field, Fill in an appropriate name for the rule
  4. Add a description
  5. Leave the Root Domain blank
  6. In the Authentication Server dropdown, select the SAML server you defined earlier
  7. In the Client Authentication dropdown, select BASIC
  8. In the Server Authentication dropdown, select NONE
  9. In the Forms dropdown, select Default
  10. In the Message dropdown, enter an appropriate message
  11. In the Timeout field, enter an appropriate timeout value in seconds.

A full definition of the fields in the Authentication Rule section can be found in the EdgeADC Admin Guide.

Testing the SAML Definition

In order to test the SAML definition, you will need to open the browser on the client and browse to the Virtual Service IP address. You should be presented with the login form on the Azure AD. Enter the credentials you defined earlier and log on.  A successful log on will display your application.

Configuring the EdgeADC for Kerberos Authentication

The method for configuring a Kerberos authentication method has been made purposely simple. However, there are a number of required steps to perform on the Active Directory server before the ADC can be configured correctly.

Create a KCD User

The first thing you will need to do is to create a User that is utilised as a App Delegation Account.

We have used a username of kcdu in our example above.

The next step is to edit the servicePrincipleName. In order to do this, you will need to use the Attribute Editor tab.

  • Click the Attribute Editor tab
  • Scroll down and find servicePrincipleName
  • Select, right click and choose Edit.
  • Type http/kcdu (use your own chosen user name) in the value field and click Add
  • Click apply and OK
  • Close the User Properties dialog. This is required to see the Delegation tab

The next step is set up the Delegation portion for the user.

  • Open the user Properties for the user just created
  • You will now see the Delegation tab
  • Click the Delegation tab
  • Select Trust this user for delegation to specified services only
  • Select Use any authentication protocol
  • Add the Real Servers that have been joined to the Domain (image is only an example and does not reflect actual servers)
  • Select the Expanded checkbox – will show the full details
  • Click OK

Note:

Configure the SPN for the Application/Website as needed. When the application pool identity is established, access the application. To use the FQDN name to access the IIS application, navigate to the Real Server command prompt and enter the SetSpn command, accompanied by the necessary parameters.

Configuring Kerberos On EdgeADC

Configuring the Kerberos Realm and associated modules is extremely simple to do.

Earlier in this guide, you will have created an Authentication Server. You now need to add a Kerberos Realm and make an Authentication Rule for allocation.

Creating the Kerberos Realm

  • Navigate to Library > Authentication on the EdgeADC.
  • Scroll down until you see the Kerberos Realms section
  • Click Add Realm
  • Enter the details as can be seen in the form
  • Click Update once done.

The Kerberos Realm has now been added.

Creating the Authentication Rule

  • Click Add Rule
  • Enter the details for each field in the form
  • Click Update
  • Click on the Authentication Server menu, and select the Authentication Server you defined
  • Click on the Client Authentication menu, and select the Forms method
  • Click on the Server Authentication menu and select the Kerberos Realm you defined
  • Click on the Form menu and select the Default form, or the form you have customized
  • Add a Message that you would like users to see on the form
  • Choose the appropriate Same Site option from the Same Site menu
  • Add an appropriate timeout for form entry
  • Click Update

Redirecting Users to Kerberos Authentication

In order for users to be presented with a Kerberos login prompt, the  EdgeADC requires to be configured to redirect the initial connection request for authentication.

This is done using the EdgeADC’s flightPATH technology, a zero-code traffic management rule creation system.

We will assume that you have created the VIP/VS for ingress using the HTTP protocol Service type, and allocated the Real Servers together with the required SSL certificates and other connection parameters such as the Load Balancing Policy.

We will also assume that you have defined the Authentication Server, Kerberos Realm and Authentication Rule.

Creating the flightPATH Rule

  • Navigate to Library > flightPATH
  • Click Add New
  • A new flightPATH is added to the list, with blank fields, ready for configuration.
  • Fill out the flightPATH name and description
  • Click Update
  • Now click on Add New in the Action section at the bottom of the page
  • Select Authentication from the Action menu field
  • Select the KCD Authentication Rule you defined earlier
  • Click Update
  • The flightPATH rule has now been created

Applying the flightPATH Rule to the Virtual Service

You will now add the flightPATH rule to the HTTP service you have created.

Traffic coming into the EdgeADC will be offloaded, and inspected by flightPATH. The Authentication flightPATH rule will then redirect the user to the Authentication server you have defined within the Authentication Rule. This will be your Azure AD server and will specify that the authentication method will be Kerberos. Once authenticated, the user will be sent to the Real Servers.

  • Log into the EdgeADC and select the Virtual Service you are going to use
  • Click the flightPATH tab in the Real Servers section
  • Locate the flightPATH rule you have created in the left side box
  • Then drag the rule to the right side Applied flightPATHs box, or click the right button to move the rule
  • The rule is enabled instantly

All traffic now entering the VIP will be sent to the authentication server for approval.

Testing the Implementation

Before you can test the implementation, you will need to create a user called beedgy in your Edgenexus Azure AD integration. Once you have done this, please contact Edgenexus Support and work with them to understand how to add users into the Edgenexus Azure AD Integration platform. Please note that users must not only be added to the system, but also activated before using SSO.

Table of contents