IT people wear many hats. This guide was written for a couple audiences, 1) the IAM administrator (Identity and Access Management or SSO jedi), and 2) the security administrator (person configuring the Web Gateway Cloud Service). The IAM admin can follow the first half (configure the identity provider), and the security admin can pick up on the rest (configure the Web Gateway Cloud Service). We hope this document meets the needs for both audiences, if it doesn't, drop a comment below and we'll see what we can do to fix it.
SAML (Security Assertion Markup Language) provides a way for people who can authenticate and identify users (identity providers) a means to relay information to people who provide services (service providers) without needing a direct connection between the two. In an on-premise world, services and identity providers exist in the same environment. If your proxy server needs to talk to your active directory server, just configure them to talk to each other. In the cloud it's not that simple. With SAML, the client acts as the relay between the identity provider and the service provider. The client is provided with a signed token from the identity provider, and the client will present this token to the service provider to verify. Once the token is verified, the service provider grants the client access to the requested service.
In our case, the Web Gateway Cloud Service is using SAML to authorize unknown clients and grant access to our services. So when a user makes a request to the Web Gateway Cloud Service for filtering, we ask them for their email address, and we redirect them to your enterprise authentication service (like ADFS or Google).
The answer depends on your requirements and supporting infrastructure.
As providers are requested, more videos will be added to demonstrate their configuration.
Download Video Here (Configuring ADFS v1.mp4), in case you have problems playing the video in the browser.
SAML is a generic claims based protocol, many different identity providers support it. We'll cover the most common providers, if you have any you want added, drop a comment below.
Active Directory Federated Services (ADFS) is an extension of Active Directory which makes it's services available to a wider audience and a controlled manner.
Bleep boop bleep, open the management console for ADFS. Can be found under Tools in the Server Manager Dashboard. If you don't see it, it's probably not installed.
Add a Relying Party Trust
We now need to configure a relying party. This tells ADFS that it's OK to relay SAML responses to the Web Gateway Cloud Service. This also defines how ADFS should behave when it receives claims for this service. To add a relying trust, click the link on the right which says Add Relying Party Trust... this will open a wizard to walk you through the steps.
Follow the steps in the wizard according to the information below. Keep in mind that this may vary depending on your ADFS server configuration.
For the sake of transparency and "completeness", all screenshots of the wizard are shown below.
Setting up claim rules, enables ADFS (identity provider) to relay user and group information to the Web Gateway Cloud Service (service provider).
In order for the Web Gateway Cloud Service to validate SAML requests, it will inspect the SAML request's signature and verify it using the public key from ADFS. As such, we need to export it and import it into the Web Gateway Cloud Service (at a later step).
Azure AD is Microsoft's cloud based identity provider. It allows organizations to run completely from the cloud or in a hybrid manner (syncing on-premise AD with the Cloud).
Go to Microsoft Azure, login, and in the menu click on Azure Active Directory. Click on "Enterprise Applications", and click "New Application".
Now we must create an application with in Azure AD, this enables the Azure AD to relay user information to the Web Gateway Cloud Service.
In order for group information to be passed in the SAML response from Azure, we must enable it in the Application manifest. To do this, we must change a config file.
Once the enterprise identity provider is configured, we can proceed to configuring the Web Gateway Cloud Service. To Configure the Web Gateway Cloud Service, open the main menu and click Authentication Settings under the Web Protection heading.
Below is ADFS specific configuration for the Web Gateway Cloud Service.
Azure AD Specific Configuration
Below is Azure AD specific configuration, please reference it.
Using a proxy.pac or wpad file is best to redirect traffic to the cloud service. This will allow for exceptions which are required for SAML to work.
For quick testing you can configure the browser to point to the Web Gateway Cloud Service as a proxy.
Configure the browser to point to your specific proxy address (i.e. c111111.saasprotection.com, where 111111 is your customer ID) for SAML Authentication specify proxy port 8084. In the Exceptions we've added our organizations domain (tangomark.com), this will allow the browser to communicate directly to the identity provider as configured above.