To enhance security and improve user experience, F5 NGINX Plus (R29+) now has support for Security Assertion Markup Language (SAML). A well-established protocol that provides single sign-on (SSO) to web applications, SAML enables an identity provider (IdP) to authenticate users for access to a resource and then passes that information to a service provider (SP) for authorization.
In this blog post, we cover step-by-step how to integrate NGINX with Microsoft Entra ID, formerly known as Azure Active Directory (Azure AD), using a web application that does not natively support SAML. We also cover how to implement SSO for the application and integrate it with the Microsoft Entra ID ecosystem. By following the tutorial, you’ll additionally learn how NGINX can extract claims from a SAML assertion (including UPN, first name, last name, and group memberships) and then pass them to the application via HTTP headers.
The tutorial includes three steps:
- Configuring Microsoft Entra ID as an IdP
- Configuring SAML settings and NGINX Plus as a reverse proxy
- Testing the configuration
To complete this tutorial, you need:
- NGINX Plus (R29+), which you can get as a free 30-day trial
- A free or enterprise Microsoft Entra ID account
- A valid SSL/TLS certificate installed on the NGINX Plus server (this tutorial uses
dev.sports.com.crt and dev.sports.com.key) - To verify the SAML assertions, which can be done by downloading the public certificate
demonginx.cerfrom the IdP
Note: This tutorial does not apply to NGINX Open Source deployments because the key-value store is exclusive to NGINX Plus.
Using NGINX Plus as a SAML Service Provider
In this setup, NGINX Plus acts as a SAML SP and can participate in an SSO implementation with a SAML IdP, which communicates indirectly with NGINX Plus via the User Agent.
The diagram below illustrates the SSO process flow, with SP initiation and POST bindings for request and response. It is critical to again note that this communication channel is not direct and is managed through the User Agent.
Figure 1: SAML SP-Initiated SSO with POST bindings for AuthnRequest and Response
Step 1: Configure Microsoft Entra ID as an Identity Provider
To access your Microsoft Entra ID management portal, sign in and navigate to the left-hand panel. Select Microsoft Entra ID and then click on the directory’s title that requires SSO configuration. Once selected, choose Enterprise applications.

Figure 2: Choosing Enterprise applications in the management portal
To create an application, click the New application button at the top of the portal. In this example, we created an application called demonginx.

Figure 3: Creating a new application in Microsoft Entra ID
After you’re redirected to the newly created application Overview, go to Getting Started via the left menu and click Single sign-on under Manage. Then, select SAML as the single sign-on method.

Figure 4: Using the SSO section to start the SAML configuration
To set up SSO in your enterprise application, you need to register NGINX Plus as an SP within Microsoft Entra ID. To do this, click the pencil icon next to Edit in Basic SAML Configuration, as seen Figure 5.
Add the following values then click Save:
- Identifier (Entity ID) – https://dev.sports.com
- Reply URL (Assertion Consumer Service URL) – https://dev.sports.com/saml/acs
- Sign on URL: https://dev.sports.com
- Logout URL (Optional): https://dev.sports.com/saml/sls
The use of verification certificates is optional. When enabling this setting, two configuration options in NGINX must be addressed:
- To verify the signature with a public key, you need to set
$saml_sp_sign_authnto true. This instructs the SP to sign the AuthnRequest sent to the IdP. - Provide the path to the private key that will be used for this signature by configuring the
$saml_sp_signing_key. Make sure to upload the corresponding public key certificate to Microsoft Entra ID for signature verification.
Note: In this demo, attributes and claims have been modified, and new SAML attributes are added. These SAML attributes are sent by the IdP. Ensure that your NGINX configuration is set up to properly receive and process these attributes. You can check and adjust related settings in the NGINX GitHub repo.
Download the IdP Certificate (Raw) from Microsoft Entra ID and save it to your NGINX Plus instance.

Figure 5: Downloading the IdP Certificate (Raw) from Microsoft Entra ID

Figure 6: Adding a new user or group
In Microsoft Entra ID, you can grant access to your SSO-enabled company applications by adding or assigning users and groups.
On the left-hand menu, click User and groups and then the top button Add user/group.
Step 2: Configure SAML Settings and NGINX Plus as a Reverse Proxy
Ensure you have the necessary certificates before configuring files in your NGINX Plus SP:
- Certificates for terminating TLS session (
dev.sports.com.crt and dev.sports.com.key) - Certificate downloaded from Microsoft Entra ID for IdP signing verification (
demonginx.cer)
Note: The certificates need to be in SPKI format.
To begin this step, download the IdP certificate from Microsoft Entra ID for signing verification. Then, convert PEM to DER format:
openssl x509 -in demonginx.cer -outform DER -out demonginx.der
In case you want to verify SAML SP assertions, it’s recommended to use public/private keys that are different from the ones used for TLS termination.
Extract the public key certificate in SPKI format:
openssl x509 -inform DER -in demonginx.der -pubkey -noout > demonginx.spki
Edit the frontend.conf file to update these items:
ssl_certificate– Update to include the TLS certificate path.ssl_certificate_key– Update to include the TLS private key path.
In production deployment, you can use different backend destinations based on the business requirement. In this example, the backend provides a customized response:
“Welcome to Application pagen My objectid is $http_objectidn My email is $http_mailn”;
We have modified the attributes and claims in Microsoft Entra ID by adding new claims for the user’s mail and objectid. These updates enable you to provide a more personalized and tailored response to your application, resulting in an improved user experience.

Figure 7: Modified attributes and claims in Microsoft Entra ID
The next step is to configure NGINX, which will proxy traffic to the backend application. In this demo, the backend SAML application is publicly available at https://dev.sports.com.
Edit your frontend.conf file:
For the attributes saml_attrib_mail and saml_attrib_ objectid to reflect in NGINX configurations, update the key-value store part of saml_sp_configuration.conf as follows:
Next, configure the SAML SSO configuration file. This file contains the primary configurations for the SP and IdP. To customize it according to your specific SP and IdP setup, you need to adjust the multiple map{} blocks included in the file.
This table provides descriptions of the variables within saml_sp_configuration.conf:
| Variable | Description |
|---|---|
saml_sp_entity_id | The URL used by the users to access the application. |
saml_sp_acs_url | The URL used by the service provider to receive and process the SAML response, extract the user’s identity, and then grant or deny access to the requested resource based on the provided information. |
saml_sp_sign_authn | Specifies if the SAML request from SP to IdP should be signed or not. The signature is done using the SP signing key and you need to upload the associated certificate to the IdP to verify the signature. |
saml_sp_signing_key | The signing key that is used to sign the SAML request from SP to IdP. Make sure to upload the associated certificate to the IdP to verify the signature. |
saml_idp_entity_id | The identity that is used to define the IdP. |
saml_idp_sso_url | The IdP endpoint to which the SP sends the SAML assertion request to initiate the authentication request. |
saml_idp_verification_certificate | The certification used to verify signed SAML assertions received from the IdP. The certificate is provided by the IdP and needs to be in SPKI format. |
saml_sp_slo_url | The SP endpoint that the IdP sends the SAML LogoutRequest to (when initiating a logout process) or the LogoutResponse to (when confirming the logout). |
saml_sp_sign_slo | Specifies if the logout SAML is to be signed by the SP or not. |
saml_idp_slo_url | The IdP endpoint that the SP sends the LogoutRequest to (when initiating a logout process) or LogoutResponse to (when confirming the logout). |
saml_sp_want_signed_slo | Specifies if the SAML SP wants the SAML logout response or request from the IdP to be signed or not. |
The code below shows the edited values only for this use case at saml_sp_configuration.conf.
Note: Make sure the remaining parts of the configuration file still appear in the file (e.g., the key-value stores). Also ensure that you properly adjust the variables within the saml_sp_configuration.conf file based on your deployment.
Step 3: Testing the Configuration
Two parts are required to test the configuration:
- Verifying the SAML flow
- Testing the SP-initiated logout functionality
Verifying the SAML Flow
After configuring the SAML SP using NGINX Plus and the IdP using Microsoft Entra ID, it is crucial to validate the SAML flow. This validation process ensures that user authentication through the IdP is successful and that access to SP-protected resources is granted.
To verify the SP-initiated SAML flow, open your preferred browser and type https://dev.sports.com in the address bar. This directs you to the IdP login page.

Figure 8: The IdP login page
Enter the credentials of a user who is configured in the IdP’s login page. The IdP will authenticate the user upon submitting.

Figure 9: Entering the configured user’s credentials
The user will be granted access to the previously requested protected resource upon successfully establishing a session. Subsequently, that resource will be displayed in the user’s browser.

Figure 10: The successfully loaded application page
Valuable information about the SAML flow can be obtained by checking the SP and IdP logs. On the SP side (NGINX Plus), ensure the auth_token cookies are set correctly. On the IdP side (Microsoft Entra ID), ensure that the authentication process completes without errors and that the SAML assertion is sent to the SP.
The NGINX access.log should look like this:
While the NGINX debug.log looks like this:
Testing the SP-initiated Logout Functionality
SAML Single Logout (SLO) lets users log out of all involved IdPs and SPs with one action. NGINX Plus supports SP-initiated and IdP-initiated logout scenarios, enhancing security and user experience in SSO environments. In this example, we use an SP-initiated logout scenario.
Figure 11: SAML SP-Initiated SLO with POST/redirect bindings for LogoutRequest and LogoutResponse
After authenticating your session, log out by accessing the logout URL configured in your SP. For example, if you have set up https://dev.sports.com/logout as the logout URL in NGINX Plus, enter that URL in your browser’s address bar.

Figure 12: Successfully logging out of the session
To ensure a secure logout, the SP must initiate a SAML request that is then verified and processed by the IdP. This action effectively terminates the user’s session, and the IdP will then send a SAML response to redirect the user’s browser back to the SP.
Conclusion
Congratulations! NGINX Plus can now serve as a SAML SP, providing another layer of security and convenience to the authentication process. This new capability is a significant step forward for NGINX Plus, making it a more robust and versatile solution for organizations prioritizing security and efficiency.
Learn More About Using SAML with NGINX Plus
You can begin using SAML with NGINX Plus today by starting a 30-day free trial of NGINX Plus. We hope you find it useful and welcome your feedback.
More information about NGINX Plus with SAML is available in the resources below.
About the Author

Related Blog Posts
Secure Your API Gateway with NGINX App Protect WAF
As monoliths move to microservices, applications are developed faster than ever. Speed is necessary to stay competitive and APIs sit at the front of these rapid modernization efforts. But the popularity of APIs for application modernization has significant implications for app security.
How Do I Choose? API Gateway vs. Ingress Controller vs. Service Mesh
When you need an API gateway in Kubernetes, how do you choose among API gateway vs. Ingress controller vs. service mesh? We guide you through the decision, with sample scenarios for north-south and east-west API traffic, plus use cases where an API gateway is the right tool.
Deploying NGINX as an API Gateway, Part 2: Protecting Backend Services
In the second post in our API gateway series, Liam shows you how to batten down the hatches on your API services. You can use rate limiting, access restrictions, request size limits, and request body validation to frustrate illegitimate or overly burdensome requests.
New Joomla Exploit CVE-2015-8562
Read about the new zero day exploit in Joomla and see the NGINX configuration for how to apply a fix in NGINX or NGINX Plus.
Why Do I See “Welcome to nginx!” on My Favorite Website?
The ‘Welcome to NGINX!’ page is presented when NGINX web server software is installed on a computer but has not finished configuring
