Web Gateway Cloud Service: Configuring SAML Authentication

Version 17

     

    Preface

    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.

     

    Introduction

    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).

     

    Should I be using SAML?

    The answer depends on your requirements and supporting infrastructure.

    • If McAfee Client Proxy (MCP) is not an option, then SAML is ideal for un-managed clients.
    • Any traffic coming in to the Web Gateway Cloud Service over port 8084 is redirected for SAML authentication.
    • In order to implement SAML authentication you will need an enterprise identity provider like ADFS, Google, or similar. This will authenticate and relay user information back to the Web Gateway Cloud Service, which is used for filtering users.

     

    Video Walkthrough

    As providers are requested, more videos will be added to demonstrate their configuration.

     

    Active Directory Federation Services (ADFS) Video

    Download Video Here (Configuring ADFS v1.mp4), in case you have problems playing the video in the browser.

     

     

     

    Configuring your enterprise identity provider

    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 Federation Services (ADFS)

    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.

     

    Open the ADFS Management console

    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.

     

     

    Relying Party Trust wizard

    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.

     

        • On Welcome click Next.
        • On Select Data Source select Enter data about the relying party manually and click Next.
        • On Specify Display Name type a name like "McAfee Web Gateway Cloud Service" and click Next.

     

        • On Choose Profile select AD FS profile and click Next.
        • On Configure Certificate click Next.
        • On Configure URL check Enable support for the SAML 2.0 WebSSO protocol and type https://saml.saasprotection.com/saml in as the service URL.

     

        • On Configure Identifiers type https://saml.saasprotection.com/saml and click Add, then click Next.
        • On Configure Mutli-factor Authentication Now? select I do not want to configure... and click Next.
        • On Choose Issuance Authorization Rules select Permit all users to access this relying party and click Next.

     

     

        • On Ready to Add Trust click Next.
        • On Finish make sure the box for Open the Edit Claim Rules... is checked. This will open a new dialog for adding claims rules.
        • If you lose the Edit Claim Rules... dialog, it can be accessed by right clicking on the newly added Relying party.

     

    Configure claim rules

    Setting up claim rules, enables ADFS (identity provider) to relay user and group information to the Web Gateway Cloud Service (service provider).

     

        • Click Add Rule...
        • On Choose Rule Type select Send LDAP Attributes as Claims from the dropdown and click Next.
        • On Configure Claim Rule give the rule a name like "Send Attributes". From the Attribute store dropdown, select Active Directory. In the Mapping of LDAP attributes table select SAM-Account-Name and Token-Groups - Unqualified Names under the LDAP Attribute column. Select Windows account name and Group under the Outgoing Claim Type. Click Finish.
        • On the original Edit Claim Rules... dialog the Send Attributes rule should appear with "Windows account name, Group" appearing as the Issued Claims. Click OK.

     

     

    Configure an additional endpoint

    Since ADFS is case-sensitive to the URL, we must configure both https://saml.saasprotection.com/saml and https://saml.saasprotection.com/SAML as endpoints in our relying trust.

     

        • Right click on the Relying Party Trust (i.e. "McAfee Web Gateway Cloud Service") and click Properties.
        • Click the Endpoints tab. On the Endpoints tab, "https://saml.saasprotection.com/saml", should already be listed as an endpoint with an index of 0, and Binding set to POST.
        • Click Add SAML..., this will open the Add an Endpoint dialog.
        • Under Binding select POST, Increment the Index to 1, and type https://saml.saasprotection.com/SAML (notice the upper case SAML), and click OK.
        • On the original Properties dialog, you should see both URLs listed, one with lowercase /saml, the other with uppercase /SAML. Click OK.

     

     

     

    Export the ADFS token signing public key

    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).

     

        • In the ADFS manager navigate in the tree to AD FS > Service > Certificates. Right click on the certificate listed below the Token-signing header, click View Certificate...
        • With the certificate open, move to the Details tab, then click Copy to File...
        • Click Next on the first step of the Certificate Export Wizard. On the second step select Base-64 encoded X.509 (.CER) click Next.
        • Save the file to some place you will find it. We need to import this file into the Web Gateway Cloud Service.

      

     

     

    Azure Active Directory

    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).

     

    Open Azure AD

    Go to Microsoft Azure, login, and in the menu click on Azure Active Directory. Click on "Enterprise Applications", and click "New Application".

     

    Creating the Enterprise 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.

        • Choose "Non-Gallery application" from the New Application screen.
        • From the Quick Start page, select "Configure single sign-on".
        • From the Mode dropdown, select "SAML-based Sign-on".

     

        

     

        • For the Domains and URLs, use "urn:mcafee:webgateway:cloudservice" as the Identifier, and use "https://saml.saasprotection.com/saml" as the Reply URL and Sign on URL.
        • For the User Attributes, select "user.userprincipalname" as the User Identifier (this may vary depending on your reporting requirements).
        • Additional attributes can be added by checking the box for "View and edit all other user attributes", then clicking the "Add attribute" option. This may be useful if you have custom attributes you want to leverage in the Web Gateway Cloud Service policy.

     

     

        • Download/Create the SAML Signing Certificate, once created, click the download for "Certificate (Base64)".
        • Under Advanced certificate signing settings, the defaults work nicely (Signing Option: Sign SAML assertion, Signing Algorithm: SHA-256).

     

     

     

     

    Enable Security Groups

    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.

        • Navigate to the Azure AD landing page and click on "App Registrations".
        • Select the "McAfee Web Gateway Cloud Service" from the available applications.
        • Once in the application settings pane, click "Manifest".

     

     

        • A text editor should appear in a new pane, find the line for "groupMembershipClaims" by default it's set to null. Change it from null to SecurityGroup.
        • Once groupMembershipClaims is set to SecurityGroup, Azure will now pass group information in the form of UUIDs to the Web Gateway Cloud Service.

    <Attribute Name="http://schemas.microsoft.com/ws/2008/06/identity/claims/groups">
     <AttributeValue>47e6e617-xxxx-4755-b334-a92c1a823e85</AttributeValue>
     <AttributeValue>f3d48fe9-xxxx-4b72-9d61-4cf0e1b0ff6e</AttributeValue>
     <AttributeValue>79d5ff98-xxxx-486e-ac66-5241fe0a2eb5</AttributeValue>
    </Attribute>
    

     

     

    Configuring Web Gateway Cloud Service Authentication

    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.

     

     

    ADFS Specific Configuration

    Below is ADFS specific configuration for the Web Gateway Cloud Service.

     

        • Select SAML under Authentication Settings.
        • Click the Pencil icon and check the box for Enable SAML Authentication.
        • For Domain(s) configure any domains that you will be authenticating for; in the example "tangomark.com" is configured. Use comma as a delimiter if you have multiple.
        • For the Request Entity ID enter https://saml.saasprotection.com/saml (remove any extra spaces).
        • For Identity Provider specify the URL where your clients use SSO, in the example the default for ADFS was chosen, but this will vary depending on your configuration.

     

     

     

    Getting Cert infov3.gif

     

    Azure AD Specific Configuration

    Below is Azure AD specific configuration, please reference it.

     

        • Select SAML under Authentication Settings.
        • Click the Pencil icon and check the box for Enable SAML Authentication.
        • For Domain(s) configure any domains that you will be authenticating for; in the example "corp.tangomark.com" is configured. Use comma as a delimiter if you have multiple.
        • For the Request Entity ID enter "urn:mcafee:webgateway:cloudservice".
        • For Identity Provider specify the URL that Azure generated. Example: https://login.microsoftonline.com/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxx/saml2

     

     

    Getting Cert infov3.gif

     

    Configuring the Browser

    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.

     

    Browser Proxy Settings

    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.

     

     

     

    Troubleshooting

    • Firefox Add-On: SSO Tracer - A useful tool for troubleshooting generic SAML issues. It provides the ability to examine the SAML requests and responses.
    • Windows Event Logs - On the ADFS server, there is a special home for ADFS related events in event viewer.

     

    Changelog

    • 2017-05-01 - Azure AD Configuration Added
    • 2016-11-22 - Guide Created