Introduction

Cisco Secure Firewall software release 7.6 introduces a new feature enforcing active authentication of users trying to connect through the firewall, using SAML-based authentication with Azure EntraID. This update enhances the user awareness toolset of Cisco Secure Firewall with support of Azure identity store, a popular choice among cloud-first companies.

By integrating with Azure EntraID, Cisco Secure Firewall allows organisations to build access policies based on user roles and attributes providing more secure and focused firewall enforcement. The use of SAML protocol simplifies user authentication process and streamlines access experience.

Background Information

Traditionally, firewalls performed policy enforcement based on information available in the forwarded network packet - source and destination IP addresses or TCP/UDP ports. As the network evolved from static desktop computers with fixed IP address to an extremely mobile workforce with laptops and smart devices, the traditional IP to role mapping become inadequate for configuring least privilege access policies.

Active Authentication is one of the methods of learning identity, where users are required to provide credentials to verify their authorization before gaining access to network resources. The firewall limits access of a network endpoint and sets up a mechanism to interactively inform the user about the restrictions and poll for the credentials. One of the most commonly used methods for active authentication is the captive portal, which intercepts and redirects web traffic originating from unauthorized computers to a login portal hosted on the firewall. Upon successful authentication in the captive portal, the firewall associates the username with the source IP address of the endpoint. From that moment on the firewall can categorize network packets to be originated from a specific user, thus allowing for role based policy control.

The Security Assertion Markup Language (SAML) protocol allows users to authenticate with a single set of credentials to a centralized identity provider and gain access to multiple systems or services. Version 7.6 introduces SAML protocol authentication against Azure EntraID as a new authentication method for captive portal, in addition to the existing support for Microsoft Active Directory and OpenLDAP.

SAML authentication enables the firewall to redirect captive portal user authentication to Azure EntraID. The user authenticates to EntraID with username, password, and MFA if configured. Once the user identity is verified, Azure sends an authentication token back to the firewall, signalling successful authorization.

📘

To support the new SAML captive portal authentication functionality, a new SAML - AzureAD Realm configuration construct is introduced. The new realm type supports two configuration types:

• Passive authentication with ISE - backward compatibility with Azure AD realm available in previous releases of software
• Passive authentication or captive portal with AzureAD - new converged realm construct supporting passive authentication with ISE and active authentication with EntraID

How it works

The diagrams below walk you through an exemplary user connection subjected to active authentication with EntraID SAML SSO.

1. The user opens a browser and types in the address of a web page to connect to example.com. The firewall's policy is configured to impose active authentication of users reaching out to this destination and the user has not authenticated yet.

📘

TLS Decryption Requirement

The user's browser directs the request to example.com through an encrypted HTTPS connection. In order to interact with the user and run the SAML authentication flow, the firewall must intercept the HTTP GET request and redirect the user's browser to itself. TLS decryption configuration is required to provide firewall a capability to inject an HTTP 300 redirect into the encrypted HTTPS connection.

For more details on how to configure TLS decryption refer to Decryption Policy

2. The firewall intercepts client's GET request and redirects the browser to authentication service hosted on the firewall. The URL of the authentication service, captive.acme.local in our example, is configured as Base URL in the SAML Realm setup.

3. The user's browser redirects to the the authentication service captive portal hosted on the firewall. Since this connection is TLS protected, the firewall must present a certificate that is trusted by the browser. This is the Service Provider Certificate you configure in SAML Realm setup.

👍

Ensure the Service Provider Certificate is valid for the name you set to your Base URL. When issuing the certificate, include the Base URL in Subject Alternative Name (SAN) or Common Name (CN). In our example, the SP certificate contains "captive.acme.local" in the SAN field.

4. Now, the firewall initiates the SAML flow to authenticate the user against the external Identity Provider (SAML IdP). The firewall looks up the IdP/SP metadata details to construct SAML Authentication Request and figure out the authentication Single Sign-On URL hosted by SAML IdP. Firewall replies to the user's browser with HTTP 3xx message with SAML Request embedded in the redirected location URL.

👍

In the SAML flow the firewall does not communicate directly with SAML IdP. The trick used by the protocol is to "tunnel" SAML messages via the client's browser. The firewall and SAML IdP redirect user's browser back and forth to each other with SAML messages embedded in the redirect location URLs or POST body messages.

5. The user browser redirects to Azure EntraID single-sign-on URL provided by the firewall. The SAML Request constructed by the firewall in the previous step is forwarded to EntraID inside the requested URL.
6. EntraID authenticates the user with username, password and MFA (if configured). Upon success the IdP constructs a SAML Assertion message containing user authorization status, to be forwarded back to the firewall.
7. SAML IdP signals success to the user and shares the SAML Assertion.

8. The client returns back to the firewall and connects to Assertion Consumer Service (ACS) URL. The browser sends a POST request with SAML Assertion message obtained from EntraID in the previous step. A valid SAML Assertion message proves to the firewall that the user successfully authenticated to the external entity - Azure EntraID SAML Identity Provider.
9. The firewall creates a dynamic IP-to-user mapping in the identity cache that binds the IP address of the PC with identity of the user authorised by EntraID.

10. The user's browser connects again to example.com, as attempted in the first place. This time, when processing the flow, the firewall finds a corresponding IP-to-user mapping in the identity cache and allows the traffic to pass through according to policy. In the diagram you can see an Access Control Policy rule with EntraID user group in the source matching criteria.