Web Security Service

English

About SAML Authentication

WSS
 supports Security Assertion Markup Language (SAML) authentication, which enables you to deploy the cloud solution and continue to use your current SAML deployment for authentication.
REQUIREMENT:
 Only the Firewall/VPN and Explicit Proxy connectivity methods with Captive Portal enabled support SAML integration.

SAML Review—Federation

Symantec
 assumes that you are familiar with SAML authentication. This document provides SAML information as it relates to
WSS
.
Federation
 allows access management to occur across organizational boundaries. This standard allows two organizations to share information without compromising identities or revealing performed services.
SAML authentication contains two components:
  • Identity Provider (IdP)—Identify stores, which might contain a back-end directory of users. IdPs authenticate your users.
  • Service Provider (SP)—Provides users with access to applications or services. In this deployment,
    WSS
     is the SP.
Your supported IdP and
WSS
 must
federate
, or establish trust, before user authentication can occur. The
WSS
 portal provides a configuration screen where you enter or import your IdP entity metadata.
WSS
 and the IdP exchange data in XML documents called
assertions
, which are sent to the Single Sign-On (SSO) Post or Redirect endpoints. After a user authenticates, the IdP sends an authentication assertion and the service establishes an authenticated session with the appropriate authorization for the user.

Identity Provider Technical Requirements

  • WSS
     supports all SAML-compliant Identity Servers.
  • To be compatible with
    WSS
    , the IdP server must be capable of sending an assertion with a
    NameID
     that includes the user name and group information.
  • Other
    WSS
    -required features include the following:
    • WSS
       integration requires RSA or DSA public keys with a key strength of at least 2048.
    • Use REDIRECT binding for
      AuthRequests
      . You can also use POST binding. The POST binding must be used for
      AuthResponses
      .
    • Assertions cannot be encrypted.
    • Must include a signing certificate with assertion (x509Certificate tab). For the signing certificate, use SHA2. SHA1 is supported but not recommended. MD5 is
      not
       supported.
    • WSS
       supports adding multiple signing certificates from the same IdP. This is required to handle the use case where an IdP's current signing certificate is about to expire and a new signing certificate will take over.
  • Consider the following best practices:
    • To avoid looping, add an authentication bypass entry for domain of the IdP server. See Exempt From Authentication.
    • A redirect to the SAML IdP server from within a CORS-enabled application causes failure. You can verify this by using developer tools on the console. Whenever possible, use the IP Surrogate method instead. If Cookie Surrogate is the only option, set longer timeout durations.
      The redirect issue is not encountered if the connectivity method is SEP with the Roaming SAML token.
    • WSS
       uses IP surrogates where possible for the SAML authentication mode. If it is imperative that you require the
      origin-cookie-redirect
       mode, which means it is compatible only with user-agents that can follow redirects and that support cookies, contact
      Symantec
       Technical Support.
    • With SAML integrated,
      WSS
       cannot authenticate explicit HTTPS requests without SSL Intercept enabled.

Tested Identity Providers

While any IdPs that satisfy the Technical Requirements listed in the previous section should work.
Symantec
 tested and documented the following IdPs.
  • Native to
    WSS
     methods.
    • Symantec
       tested and supports Microsoft® Active Directory Federation Services (AD FS) 2.0/3.0.
    • You can use the
      Auth Connector
       server as the IdP. The domain controller scales well, provides the group memberships, and automatically handles complexities, such as nested groups.
      For more detailed information, see About the
      Auth Connector
       as a SAML IdP      .
  • Symantec
     tested the
    WSS
     with the following SAML IdPs.
    • Symantec VIP Access Manager (enables Single Sign-On)
    • Google G Suite
    • Microsoft Azure (with SCIM 2.0)
    • Okta
    • Ping ID

Flow Overview

The following diagram illustrates what occurs when a user requests a website that requires authentication.
SAML Flow

SAML Flow

1
—
The SP (
WSS
) intercepts the user request and redirects the web browser to the IdP. The redirect URL includes the SAML authentication request that is submitted to the IdP’s SSO service.
2
—
The IdP authenticates the user by asking for valid login credentials or checking for valid session cookies for stored credentials and sends the assertion to the browser.
3
—
The browser returns the assertion with the authentication response, which contains the user's username, to
WSS
 (however, the service is not aware of the user’s credentials).
4
—
WSS
 validates the request using the corresponding public key, which is embedded in the IdP's signing certificate, and then retrieves the user name from the
Name ID
 attribute in the assertion.
5
—
WSS
 redirects the user to the website and creates an authenticated session for the user.

More Details

The following Knowledge Base discusses SAML connections in more technical detail.

Support for Multiple AD Forests

Symantec
 suggests two methods to authenticate users spread across multiple AD forests.
  • Establish external forest trust relationships between one hub AD and the rest of the AD forests with one particular AD forest, then configure the hub AD as the IDP and federate it with
    WSS
    . In most cases, this requires bi-directional trusts.
  • If bi-directional trusts are not administratively possible, install or enable ADFS in each AD forest and then create an ADFS-level trust between each ADFS server. This allows various types of trust relationships to exist for applications that federate with ADFS.