Guidelines and Limitations for SAML 2.0

  • Threat Defense supports the following signatures for SAML authentication:

    • SHA1 with RSA and HMAC

    • SHA2 with RSA and HMAC

  • Threat Defense supports SAML 2.0 Redirect-POST binding , which is supported by all SAML IdPs.

  • The Threat Defense functions as a SAML SP only. It cannot act as an Identity Provider in gateway mode or peer mode.

  • You can enforce an access policy on a SAML-authenticated user if you have an associated identity policy with an AD realm matching the SAML domain. However, it does not work for Azure AD SAML because it requires additional mapping from the tenant ID of the Azure AD to an associated realm ID on the threat defense device.

  • Having SAML authentication attributes available in DAP evaluation (similar to RADIUS attributes sent in RADIUS auth response from AAA server) is not supported. Threat Defense supports SAML enabled group policy on DAP policy; however, you cannot check the username attribute while using SAML authentication, because the username attribute is masked by the SAML Identity provider.

  • Threat Defense administrators need to ensure clock synchronization between the threat defense and the SAML IdP for proper handling of authentication assertions and proper timeout behavior.

  • Threat Defense administrators have the responsibility to maintain a valid signing certificate on both threat defense and IdP considering the following:

    • The IdP signing certificate is mandatory when configuring an IdP on the threat defense.

    • The threat defense does not do a revocation check on the signing certificate received from the IdP.

  • In SAML assertions, there are NotBefore and NotOnOrAfter conditions. The threat defense SAML configured timeout interacts with these conditions as follows:

    • Timeout overrides NotOnOrAfter if the sum of NotBefore and timeout is earlier than NotOnOrAfter.

    • If NotBefore + timeout is later than NotOnOrAfter, then NotOnOrAfter takes effect.

    • If the NotBefore attribute is absent, the threat defense denies the login request. If the NotOnOrAfter attribute is absent and SAML timeout is not set, threat defense denies the login request.

  • Threat Defense does not work with Duo in a deployment using an internal SAML, which forces the threat defense to proxy for the client to authenticate, due to the FQDN change that occurs during challenge/response for Two-factor authentication (push, code, password).

  • When using SAML with Secure Client, follow these guidelines:

    • Untrusted server certificates are not allowed in the embedded browser.

    • The embedded browser SAML integration is not supported in CLI or SBL modes.

    • SAML authentication established in a web browser is not shared with Secure Client and vice versa.

    • Depending on the configuration, various methods are used when connecting to the headend with the embedded browser. For example, while Secure Client might prefer an IPv4 connection over an IPv6 connection, the embedded browser might prefer IPv6, or vice versa. Similarly, Secure Client may fall back to no proxy after trying proxy and getting a failure, while the embedded browser may stop navigation after trying proxy and getting a failure.

    • You must synchronize your threat defense's Network Time Protocol (NTP) server with the IdP NTP server in order to use the SAML feature.

    • You cannot access internal servers with SSO after logging in using an internal IdP.

    • The SAML IdP NameID attribute determines the user's username and is used for authorization, accounting, and VPN session database.

  • SAML does not support Start Before Logon (SBL).

  • Multiple attributes received with a SAML assertion are not supported.