Integrate Microsoft Azure as the Cloud SWG SAML IdP.

Products

• Cloud Secure Web Gateway - Cloud SWG

Issue/Introduction

Steps to Integrate Microsoft Azure as the Cloud SWG SAML IdP.

Cause

To use Security Assertion Markup Language (SAML) authentication for Cloud SWG without an Active Directory (AD) deployed, provision Microsoft® Azure™ as the SAML Identity Provider (IdP).

Cloud SWG supports the automatic synchronization of users and groups by using an integration token.

Resolution

Step 1: Set up the Azure AD accounts

If you do not have one, you must create a Microsoft Azure account, which establishes your contact and credit card information (for verification).

1. In a browser, access: https://account.azure.com/organization
2. Complete the required fields.

a. Enter your contact Name and Email Address.
b. The Organization Name is optional. If you enter one, the Domain Name mirrors the entry (hover over the tool tip (?) to read more).
c. Click Check Availability to confirm that your domain name is not currently used by another party.
d. When complete, click Sign In (upper-right screen). The browser displays the Microsoft account login page.
e. Log in using your organization credentials.

Step 2: Add users and groups

1. In the Azure application, select Azure Active Directory (left-menu).

 

2. If your Azure account is not populated with Users or Groups, you can add them:
   a. Select Users.
   b. Select All users.
   c. Click New User. Azure displays a page to add them.
   
   
3. After you add users, you can add them to groups:
   a. Return to the Azure Active Directory page and select Groups.
   b. Select All Groups.
   c. Click Add Group. Enter the requested information.
   d. To add users to a group, on the Groups page select Members.

Step 3: Prepare Azure for Cloud SWG

The next phase is to add Cloud SWG as an application. This phase requires providing SAML Federation information that is obtained from your Cloud SWG portal.

1. Remaining in your Azure Portal, return to the main Azure Active Directory page.
   
   
2. Add the Symantec app:
   a. Select Enterprise Applications.
   b. Click New Application, then click Security. The portal displays a list of known related applications.
   c. Scroll down to (or Search for) and select Symantec Web Security Service. Click Add.
   d. Select Single sign-on, then select SAML.
   
   
3. To complete this step, you must log in to your Cloud SWG portal account (open a new browser tab) and obtain the metadata that is required to federate the two services.
   a. Navigate to Identity > SAML Authentication.
   b. Expand the SAML Authentication area.
   c. Click Download Metadata.

d. Open the download (browser) and view the contents.
e. Record the following values (for example, copy to Notepad):

• The EntityDescriptor—https://saml.threatpulse.net:8443/saml/saml_realm

• The AssertionConsumerService Location—https://saml.threatpulse.net:8443/saml/saml_realm/bcsamlpost

4. Return to the Azure Portal tab.

a. In the Identifier field, enter the EntityDescriptor value.
b. In the Reply URL field, enter the AssertionConsumerService Location value.
c. From the User Identifier drop-down list, select user.userprinciplename.
d. Click Save. The interface displays a confirmation message.

5. Scroll down to SAML Signing Certificate. If you do not have an existing active or unused certificate, click Create New Certificate to create one. Save it and make it Active. In the new certificate row, click the Metadata XML link in the Download column; save the file.

6. Return to the Cloud SWG portal page.

To get the group details please follow the below steps:

1. Go to IdP’s Single-Sign-ON àAttributes & Claims à Edit
   
2. Select ‘Add a group claim’
   
3. Select Group Claim = Group Assigned to the application
   Select Source attribute = Cloud-only group display names
   

4. Copy claim name for ‘user.groups’ from IdP

5. Copy this value to Group Attribute in Symantec Cloud SWG’s IdP configuration

 

 

 

1. Click SAML IdP Metadata: Import Metadata. Browse to the saved Azure certificate file saved in the previous step and open it. The portal populates the Entity ID, Endpoint URL, and Signing Certificate fields.
2. (Optional) Select Sign Authentication Request to have Cloud SWG sign the SAML requests that are sent to the IdP. The IdP validates who is making the authentication request. When you download it, the WSS Metadata file contains the required certificate.
3. The imported metadata also includes the Endpoint Type:

• The Redirect Endpoint option (AuthRequests) redirects the request to the SAML endpoint, which is considered to be the simpler option.
• If you selected the Sign Authentication Request option, select Post Endpoint (AuthResponses). AD FS does not accept a signed certificate from a Redirect Endpoint.

1. In the Group Attribute field, enter group.
2. Click Save.

 

Step 4: Make users available for authentication

In Azure, select which users and groups are available for the SAML authentication.

1. In the Azure Symantec Web Security Service application, select Users and Groups.
2. Click Add User.
3. Select the users to include and click Select. Azure displays the Add Assignment dialog.
4. Click Assign.

Step 5: Test SAML

To perform an immediate configuration validation, you can explicitly proxy a browser of a client on the network to Cloud SWG.

1. In the Cloud SWG portal, add a location (Connectivity > Locations). Name it SAML Azure Test, for example.
2. Set to Explicit Proxy.
3. Save the location.
   
   
4. Navigate to Identity > Authentication Policy.
5. Click Add Rule and select Explicit Proxy Locations. The Cloud SWG displays the New Rule page.
6. Click Add Sources and add the Explicit Proxy Location.
   
   
7. In the Verdict area,
8. Enable Captive Portal.
9. Select SAML.
   
   
10. Click Add Rule; click Activate.
11. Log in to the test client machine and configure the browser proxy settings to proxy.threatpulse.net:8080.
12. Restart the browser. If you see the Azure sign-in page, the SAML deployment is functioning.

• If not, retrace the configuration steps.
• If you encounter connection problems, see Troubleshoot Cloud SWG SAML Authentication Issues for possible causes and resolutions.

Step 6: Include group identities in the assertion

Azure does not return the list of groups that a given user currently belongs to in the SAML assertion for group policy enforcement. However, Azure allows for a created role for each group. By creating and mapping a role to a group, Azure returns the list of roles that a user belongs to based on their groups.

Note:For Cloud SWG group-level policy to be valid, the role values must match the name of the groups that are used in the Cloud SWG policies.

To create group-based policies in Cloud SWG, Azure provides the following steps that create roles for each user group.

Creating application roles affects the procedure in Step 4. After roles are created, users and groups that are added to the Cloud SWG SAML application no longer have Default Access as their default role. You must select the role for each user and group that you add to the application.

If a user is assigned to a specific application role and also belongs to a group that has its own assigned role, both roles are included in the assertion. For example, UserAB is assigned to roleA and belongs to groupB, which has its own assignment of roleB.

1. Complete the procedure in the following article:

https://docs.microsoft.com/en-us/azure/active-directory/active-directory-enterprise-app-role-management

You can select any string for your roles as long as the selected role names match the group names in your Cloud SWG policy. The following examples use the names roleA and roleB to match example Cloud SWG group names roleA and roleB. Azure AD returns this particular role information in plain text in the SAML assertion; thus, it must be mapped to the appropriate groups.

2. In the Azure Symantec Web Security Service application, select Users and Groups.
3. Click Add User.
4. Select groups.
   
5. Use the Search field to narrow the view from all users. This example limits the view to the group keyword.
6. Select which groups are to be susceptible to Cloud SWG policies and click Select.
7. Click Select Role.
   
8. Select which roles are to be susceptible to Cloud SWG policies.
9. Click Select.
10. Click Assign.
    
    
11. Repeat as necessary to assign all groups to roles.
12. Add the group attribute.
13. Return to the Cloud SWG application (in Azure) and select Single sign-on from the left-menu.
14. In the User Attributes area, select View and edit all other user attributes.
15. Click the Add Attribute link.
    
16. In the Name field, enter group.
17. In the Value field, enter a value that matches the Cloud SWG group name. In this example, the group name is user.assignedroles. You can use other attributes to evaluate against a specified group in the Cloud SWG policy. For example, enter “user.department” as the value to match a user.department group condition in the policy.
18. Click OK.

Step 7: Configure automatic user/group population in Cloud SWG

Provision your Azure account to manage users and groups within the Azure portal while they also automatically sync to the Cloud SWG portal. Create a non-gallery application to integrate your portal account with the Azure account through the Secure Cross-domain Identity Management (SCIM) feature. See the SCIM section in Import Users and Groups for SAML for details and prerequisites.

1. Select Azure Active Directory > Enterprise Applications.
2. Create the SCIM app.
3. Click New Application.
4. Select All and click Non-gallery application.
5. If you already have Premium AD and Enterprise Mobility Suite licenses, proceed to Step 6.

Otherwise, click Get a premium....

The Azure AD Premium and Enterprise Mobility Suite apps each have trial links. You must activate the ones that you do not currently have.

4. Returning to the Add an Application screen, Name the application. For example, symantecwss.

Click Add (bottom of screen).

5. Provision Cloud SWG:
6. Select Provisioning.
7. From the Provisioning Mode drop-down list, select Automatic.
   
   
8. Back in the Cloud SWG portal, navigate to Identity > SAML Authentication.
9. Expand the SCIM Third-Party Users & Groups Sync area.
10. Click Generate Integration Token.
    
11. The portal generates a unique SCIM URL. Click the Copy icon.
12. Return to the Azure browser tab Admin Credentials area.
    
13. In the Tenant URL field, paste the SCIM URL.
14. Return to the Cloud SWG portal tab and copy the Token.

• In the Azure portal, paste the token into the Secret Token field.
  
  

7. Scroll to the Settings area.

By default, Provisioning Status is set to Off and Scope is set to Sync only assigned users and groups.

1. Set the Provisioning Status to Off.
2. The Scope drop-down list presents two options:

• Sync all users and groups
• Sync only assigned users and groups—If you select this option, ensure that you select only users and groups that are synced to OSIAM.

Microsoft Doc

8. In the Admin Credentials area, click Test Connection. If successful, the Azure portal displays the following message: The supplied credentials are authorized to enable provisioning.

If the test fails, try generating a new SCIM URL and token.

In the Cloud SWG portal, navigate to Identity  > Users & Groups. On the Third-Party Users and Groups tab, you can see how many Users and Groups were imported in the most recent sync operation.

 

Step 8: Limit the synced attributes to the minimum required set

To improve network efficiency, limit the synced attributes so that Cloud SWG receives only the data that it requires for this feature.

1. Remaining on the Provisioning page, in the Mappings area click Synchronize Azure Active Directory Groups to customappsso.
2. In the Attribute Mapping dialog, delete all attributes except for displayName.
3. Click Save. Click Save in the confirmation dialog.

• The Azure portal displays a success message in the upper right of the screen.

4. Return to the Provisioning > Mappings area and select Synchronize Azure Active Directory Users to customappsso.
5. Delete all attributes except for externalId, active, and userName.

If deleting the name.formatted attribute causes a SchemaInvalid error when you try to save, include it in the list of attributes to keep. Then, save the settings again.

6. Click Save. Click Save in the confirmation dialog.

The Azure portal displays a success message in the upper right of the screen.

7. Click Save.