cancel
Showing results for 
Search instead for 
Did you mean: 

Web Gateway Cloud Service: Configuring SAML Authentication

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.

open dns.png


 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

key.png
 

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

 

 

 

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
Labels (1)
Comments

Thank you for your very detailed documentation Jon.  Can you provide documentation on how to setup Single Sign-On when authenticating with McAfee Client Proxy (MCP) and configuring the Rule Set.

Hi Omar,

Could you elaborate further? It might be worth it to start a Community thread, you can just tag my name with an @ symbol.

There are a number of articles on setting up MCP:

https://community.mcafee.com/docs/DOC-4384#jive_content_id_McAfee_Client_Proxy_MCP

But because of how you phrased the question, it doesnt sound like you just want to use MCP for auth (sounds like that is done), but you want it for SSO into other apps (?).

Best Regards,

Jon

Jon,

Thanks for the quick response, yes we're already using MCP with our on-premise appliance and our SaaS Web Protection.  We're wanting to implement Single Sign-On with services like SalesForce, Box and other services that i don't see that have the preinstalled connectors that come with the Web Gateway Rule Set "Single Sign On" but I believe you can do a custom connector.  From my understanding of your documentation above your explaining on how to setup Single Sign-On when MCP is not being utilized in the environment and have to setup a separate server for SAML and ADFS correct?  I believe I read somewhere that if we have MCP on the client machines then setting up Single Sign-On should be alot easier to configure since the MCP manages the authentication and passes it on when you use the Rule Set "Single Sign On".     

A few notes on successfully using SAML auth for WGCS explicit proxy with iPhone:

  • You need to bypass WGCS for the identity provider site, this is best done by using a PAC file in your proxy settings
  • You need to install and trust the WGCS SSL certificates, and the certificate for your identity provider website
  • You need to accept third party cookies

Great article. Is there anything similar that uses Novell eDirectory instead of Microsoft AD? 

 

edit : found something for those still using Novell, see https://www.novell.com/documentation/idmrbpm361/install/data/bfcbqsb.html

Configuration using VMWare Identity Manager

Thank you Doug Hopkins of Atos

Assuming an already configured VMWare Identity manager connected to AD and Airwatch exists:

In the VMware Identity Manager Catalog, create a new Web Application for SAML 2.0

Here are the Base Definition settings  ( I pulled the icon from the web, and it can be called whatever you want)

 

Fig1SAMLVM.png

 

Configuration must match most of what you set in the SAML Auth Setting in WGCS (selecting Manual settings)

Single Sign-On URL, Recipient URL and Application ID – should all be the https://saml.saasprotection.com/SAML

 

Username Value should be some static value you choose – doesn’t matter what it is

Sign Response and Sign Assertion should match WGCS

 

Fig3SAMLVM.png

Algorithms need to be  SHA256 with RSA / SHA256

Create 2 Custom Attributes

1 for “GroupID” , Format “Basic” and pick the AD filed to map and pass as the user (they are in the type ahead pre-formatted here)

2 for “GroupID” , format “Basic” and ${groupNames} is the only thing needed – even though I don’t sync any group values, I still did this based on the engineer’s recommendation

Fig4SAMLVM.png

 

From there apply the access policy for VMWare Identity users who can access this web app and save

Under Catalog -> Settings – the signing certificate key is found, as well as the Identity Provider Metadata link and XML that specifies the Entity ID and Identity Provider

User ID Attribute and Group ID Attribute need to be the custom mappings you created respectively in the web app.   – For the SaaS VMware IDM its:

Identity Provider: https://<xxxxxx>.vmwareidentity.com/SAAS/auth/federation/sso

Entity ID: https://<xxxxxx>.vmwareidentity.com/SAAS/API/1.0/GET/metadata/idp.xml

Fig5SAMLVM.png

Contributors
Version history
Revision #:
4 of 4
Last update:
‎04-03-2018 07:59 AM
Updated by:
 

Community Help Hub

    New to the forums or need help finding your way around the forums? There's a whole hub of community resources to help you.

  • Find Forum FAQs
  • Learn How to Earn Badges
  • Ask for Help
Go to Community Help

Join the Community

    Thousands of customers use the McAfee Community for peer-to-peer and expert product support. Enjoy these benefits with a free membership:

  • Get helpful solutions from McAfee experts.
  • Stay connected to product conversations that matter to you.
  • Participate in product groups led by McAfee employees.
Join the Community
Join the Community