Table of Contents

 

SAML Overview

• Components of SAML SSO Solution.

• Use Cases.

• SAML Logical Flow.

• TOOLS.

• SAML Messages.

• • SAML Authentication Request.

  • SAML Authentication Response.

  • SAML Logout Request.

  • SAML Logout Response.

• IdP Metadata XML.

• SP Metadata XML.

 

 

 

SAML Overview

 

Security Assertion Markup Language 2.0 (SAML 2.0) is an XML-based standard for exchanging authentication and authorization data between security domains. SAML mainly solves two requirements in the enterprise: Web-based single sign-on across multiple entities and federated identity. Single Sign-On is achieved by sharing identity information between multiple organizations and applications. Federated identity allows a set of service providers to agree on a way to refer to a single user, even if that user is known to the providers in different guises.

 

Components of SAML SSO Solution

 

Typically, three entities participate in a SAML transaction:

• Principal (user)
• Service Provider (SP)
• Identity Provider (IdP)

 

The Service Provider is typically the application or service that a principal has requested access to, and the Identity Provider is the entity that is plugged into the identity store that carries the user's credentials. SAML does not define the techniques that an IdP can use to authenticate the user - instead, it focuses on defining the exchange of information between a SP and an IdP to indicate the authentication and authorization state of the principal. This gives IdP the freedom to use additional authentication techniques (2FA/MFA, certificate based authentication...) to authenticate the user. SAML messages use XML as the data interchange format, and are transported over HTTP with a strong requirement to secure these messages using SSL/TLS (HTTPS)

 

SAML Assertion contains information about the authentication and the user. The assertion contains information, that the receiver can use to make an access control decision. There are 3 types of Assertion statements:

 

• Authentication statement contains information such as time and method used to ensure identity of the user.

 

• Attribute statement contains information about the user such as username, phone number, address ...etc.

 

• Authorization decision statement confirms if the user is authorized to access a specified resource.

 

SAML uses security tokens containing assertions to pass information about a principal (usually an end user) between a SAML authority, that is, an identity provider, and a SAML consumer, that is, a service provider. For instance, the Identity Provider asserts that this user has been authenticated and has given associated attributes. In SAML, Identity Providers are also known as SAML authorities and Asserting Parties. Service Providers are also known as Relying Parties – due to the fact that they “rely” on information provided by an Identity Provider (Asserting Party). Identity provider forwards assertions to the Assertion Consumer Service (ACS) URL and this service validates the assertions to ensure whether the end user is authorized to gain access to application and other resources. ACS URL is important because that is the URL where the Service provider will receive and consume the assertions.

 

The lower-level communication or messaging protocols (such as HTTP or SOAP) that the SAML messages can be transported over are defined by Bindings. SAML Bindings are hooks on an endpoint that dictate how a SP & an IdP communicate. With HTTP as the transport, typical bindings include REDIRECT (HTTP 302) and POST (HTTP POST). HTTP Redirect Binding: Defines how SAML protocol messages can be transported using HTTP redirect messages (302 status code responses).  SAML requests or responses transmitted via HTTP Redirect have a SAMLRequest or SAMLResponse query string parameter, respectively. Before it's sent, the message is deflated (without header and checksum), base64-encoded, and URL-encoded, in that order. Upon receipt, the process is reversed to recover the original message. Both SPs and IDPs can transmit and receive messages using redirect or POST bindings. Due to the limitation of URL lengths in certain scenarios, HTTP Redirect is usually used when passing short messages, and HTTP POST is used when passing longer messages.

 

HTTP POST Binding: Defines how SAML protocol messages can be transported within the base64-encoded content of an HTML form control.

Palo Alto Networks SP endpoints can only accept SAML messages when transported using HTTP POST.

Another SAML terminology to be aware of is Metadata. It carries schema and endpoint information about both the IdP and the SP. Each IdP and each SP is expected to have its own metadata. IdPs and SPs typically register with each other using metadata. Typically, metadata contains information such SSO URL, issuer name, and the certificate containing the PKI "public" key. For example, a SP can use this information to trust an assertion coming from an IdP and vice-versa. SAML 2.0 provides a well-defined, interoperable metadata format that entities can leverage to bootstrap the trust process. Metadata provided by the IdP to SP contains information about IdP (such as Entity ID, SSO/SLO URL … etc) and vice-versa.

 

 

Use Cases

 

SSO for Captive Portal:

Customers would like to use our capability to launch a captive portal when an user attempts to access specific HTTP-based resources. To alleviate the need for a user to sign on multiple times, customers rely on SAML-based SSO, where, the user signs in once with their IdP, and is then permitted access to any Service Provider that is registered with the same IdP as long as the user passes any required authorization checks. In addition, these customers also use captive portal to transparently identify users (User-ID), if the user's IP/user mapping has expired. Captive portal can also be used to authenticate a known user who is attempting to access a protected resource. This capability provides the required level of security assurance to the administrators, and provides a simple, hassle-free interface to the end-users. In an organization, multiple applications can make use the same IdP to authenticate the users. Provided that the applications are using SAML and the same IdP to authenticate the users, the user get a consistent experience when they access those applications and authenticate.

 

SSO for GlobalProtect:

Customers would like to use SAML based SSO for GlobalProtect. SAML allows these enterprises to use a single architecture for SSO across all applications, and for all users on all device platforms. Since GlobalProtect runs on multiple platforms, and since SAML is platform agnostic, SAML is a perfect choice for Single Sign-On. GP Gateways and Portals will act as a SAML Service Provider, deferring the process of identity assertion to a third-party SAML Identity Provider.

 

SSO for Firewall/Panorama GUI:

Firewall and Panorama administrators seek to access the admin GUI without having to manually sign on to it. Enabling authorized administrators to directly access our GUI within an enterprise that has deployed SAML as its SSO standard reduces the user effort required to logon, and allows the firewall/Panorama to rely on a centralized authentication engine for the purposes of identity assertion.

 

 

 

SAML Logical Flow

 

In the following example, we will highlight the authentication flow for a user using captive portal. It highlights interaction between the user, resource, firewall (Service Provider) and the IdP. The authentication flow is similar for other SP endpoints (Admin UI, GlobalProtect Portal/Gateway, GlobalProtect Clientless SSL VPN)

 

 Authentication flow

 

1. User makes a request to a resource (either on a Service Provider, such as Firewall/Panorama GUI or on another web server – such as bing.com )
2. If a request to a resource is not to Firewall/Panorama GUI and if an Authentication Policy rule exists, it is executed and the user is redirected to a captive portal URL.
3. The user’s browser accesses the Captive Portal URL
4. The Service Provider creates an AuthnRequest object, which indicates how the SP wants the user authenticated. The AuthnRequest is encoded and is sent to the Identity Provider via HTTP POST or HTTP Redirect method via user’s browser. Details about SAML AuthnRequest, Response etc… will be explained in the latter half of the document.
5. If IdP has previously authenticated the user, the IdP sends a cookie that identifies the user. This cookie is stored in the browser. In continuation to the previous step (Step 4), if the user has previously authenticated with the IdP, along with the AuthnRequest, cookie stored in the browser is also sent to the IdP via user’s browser. IdP checks if it is a valid cookie. If a valid cookie does not exist, or if a cookie does not exist, the IdP authenticates the user. IdP will present login request to the browser and based on the authentication mechanism configured, the user will be authenticated. For example, a simple form-based authentication could be configured and a LDAP server can be queried to perform user lookup. The user will be presented with a login request and in the browser, user enters login credentials and posts them back to IdP. The IdP submits the login credentials to the LDAP server. LDAP server checks the credentials and sends the validation status back to the IdP.
6. The IdP creates a SAML Assertion, signs it with its private key and redirects the user back to the Service Provider via the HTTP POST method including the SAML Assertion. Using the information provided in the assertion, the SP will take appropriate decisions such as providing the user access to the protected resource.
7. Service Provider validates the SAML Assertion and XML signature provided by the IdP. It extracts the username from the SAML assertion via the username attributes and verifies the user and user group against the allow list. If access checks pass, the resource is then returned to the browser. Browser completes the connection to resource such as bing.com

 

TOOLS

 

There are some DevTools that can be loaded on to the browser (such as Chrome), that can aid in debugging SAML messages. Some of the popular chrome extensions are:

• SAML Chrome Panel
• SAML DevTools Extension

 SAML DevTools extension

 

 

 

SAML Messages

 

SAML Authentication Request

 

AuthnRequest is a SAML message that SP sends to IdP in order to initiate authentication. This message is Base64-encoded and sent to the IdP. Along with the Base64-encoded SAML Authnrequest, a Relaystate token is sent to IdP. Relaystate token is an opaque identifier that references to state information maintained at the Service Provider. This token is echoed back by the IdP in its response message.

 

 

SAML AuthnRequest

The important elements in the above AuthnRequest are:

• Assertion Consumer Service URL
• Destination URL
• Time of the request (Issue instant)
• ID of the request
• Issuer

 

Assertion Consumer Service URL is the address at the Service Provider where the response message will be sent by the IdP after an authentication is complete.

 

Destination URL is checked by the IdP to validate that the authentication request is actually meant for it. This is useful to prevent malicious forwarding of requests to unintended recipients.

 

Time of the request is checked by the IdP to verify if the request made was not too old.

ID of the request is a random number generated and it is important that it matches with the response of the request.

 

Issuer identifies the entity that generated the request message. Typically, every request and response contains an entity ID of the sender.

 

Other elements that need to be noted are the following:

 

• Protocol Binding
• Signature
• Digest Value
• X509 Certificate

 

Protocol Binding is the URI reference that identifies a SAML protocol binding to be used when returning the Response message.

 

Signature and Digest Value are used to ensure message integrity of the request and response messages. This value will be cross checked and validated on the receiving side using the same Digest Method (for example, SHA1) to ensure the integrity of the message

 

X509 Certificate: In SAML, the SP and IdP exchange public certificate key with each other. The certificates then get installed and explicitly trusted. To establish the trust of the origin of the key, certificate authority can be used. The public key included in the AuthnRequest or Response message is to indicate to the partner that the entity with the corresponding private key signed the messages. It just determines that the key belongs to the other party.

 

Fig: SAML AuthnRequest (FW GUI and Chrome Dev Tool)

 

SAML AuthnRequest

Fig: RelayState

 

RelayState

 

SAML Authentication Response

 

After the IdP authenticates the user, it creates an Base64 encoded SAML Response and forwards it to Service Provider.

As a response to the AuthnRequest, the IdP sends to SP, status and security assertions. The response will contain success status and assertions in case the user is successfully authenticated by the IdP. In case of any other failure, the response will contain the status indicating the failure reasons and it will not contain any assertions. IdP authenticates the user and the SP is not involved in this process. SP just receives the status of the authentication.

 

SAML Response 

 

Majority of the elements seen in the SAML Response are similar to the ones discussed under AuthnRequest. The ones that are not covered in AuthnRequest are discussed below.

 

• Status
• Name ID
• Session Index
• Attribute Statement and Attribute Value
• Authentication Statement

 

Status element describes whether the user was successfully authenticated or not

 

NameID is a unique identifier created by IdP to manage the life cycle of user/principal security session after a successful authentication (in this case, IdP is regarded as session authority)

 

Session Index is the unique identifier created by IdP to keep track of which SP the user/principal is doing SAML SSO (in this case, SP is regarded as session participant)

 

Attribute statement contains attributes that are associated to a user. In the above example, user’s samAccountName is being sent by the IdP to SP.

 

Authentication statement contains information such as time and method used to ensure the identity of user

 

Fig: SAML Response (FW GUI and Chrome Dev Tool)

 

SAML Response Fig: RelayState

 

RelayState

 

SAML Logout Request

 

When the user logs out of Firewall GUI, the Service Provider creates a SAML Logout request to terminate the user session. The SLO request is sent to the IdP. NameID and session index are used by the IdP and SP to terminate the user session. The IdP would ideally send a SLO request to SP for all other applications that the user has logged onto. So, when the user logs out of one application, the IdP attempts to log the user out of all other application.

 

SAML LogoutRequest

 

If Redirect is chosen as SAML HTTP Binding for SLO, then you will see the signature of the SAML Logout Request which the SP signed in the URL of GET Request

 

Fig: SAML LogoutRequest (FW GUI and Chrome Dev Tool)

 

SAML LogoutRequest

SAML Logout Response

 

For the SLO request sent to IdP by the SP, IdP sends a Logout Response indicating success or failure. The response will be signed by the IdP. The SP does the necessary cleanups before logging the user out. The SP will clear up session cookies that it has for the user. Next time, when the user tries to login, the whole SAML process restarted again. The SP can also clear session cookies for the user based on the session idle timeout and restart the SAML Authentication process when the user tries to access the application again.

 

SAML LogoutResponse

 

Fig: SAML LogoutResponse (FW GUI and Chrome Dev Tool)

 

SAML LogoutResponse

 

IdP Metadata XML

 

Sharing of trust between IdP and SP can be easily facilitated by the metadata.

In the SP (Firewall or Panorama), IdP server profile can be built using the IdP Metadata XML file provided. Information provided in the metadata is parsed and saved in the Panaroma or Firewall configuration. IdP Metadata can contain the following information:

 

• IdP Entity ID
• IdP SSO URL
• SSO binding format (SAML HTTP Binding – POST/Redirect)
• IdP SLO URL
• SLO bind format (SAML HTTP Binding – POST/Redirect)
• SAML Attributes
  • Username attribute name
  • Usergroup attribute name
  • Admin role attribute name
  • Access domain attribute name
• IdP signing certificate
• IdP WantAuthnRequestsSigned flag

 EntityDescriptor

 

SP Metadata XML

 

SP metadata can be exported from SAML Authentication Profile from Panorama/Firewall. If IdP gives an option to upload SP metadata, the exported SP metadata can be uploaded into IdP and SAML Application can be easily created. Like mentioned earlier, metadata can be leveraged to bootstrap the trust process.

 

The SP metadata may contain the following:

 

• ACS URL
• ACS binding format
• SLO URL
• SLO binding format
• Entity ID
• Signing certificate

 

EntityDescriptor