User/group synced from Azure AD using SCIM cannot getting blocked pages accessing web sites
search cancel

User/group synced from Azure AD using SCIM cannot getting blocked pages accessing web sites

book

Article ID: 247156

calendar_today

Updated On:

Products

Cloud Secure Web Gateway - Cloud SWG

Issue/Introduction

User and group information from the Azure AD synchronised to WSS using SCIM.

Content filtering policies setup to allow users/groups access to Web resources.

Both user and group based rules are failing as both users and groups that are explicitly defined in the policies to be allowed to access sites do not match.

Environment

AZure SAML IDP server.

SCIM used to sync users with WSS.

Cause

Mismatch between SCIM provisioned user information and Name Identifier information within SAML Assertion.

Resolution

Need to make sure that the

- SAML Assertion Name Identifier matches the format teh users are provisioned into WSS with via SCIM. In our example above, the users were provisioned into WSS (Web Security Service -> Identity/Users & Groups -> Third-Party Users & Groups Sync) with email addresses but the SAML assertion included the users name as per the following configuration and not email address:

CHanging this to send the email address fixed the issue:

2. The group attribute name defined in WSS MUST match that sent with the Assertion group information: From the customers environment, the SAML group defined in the WSS Portal was simply 'group' yet when looking at the assertion returned, it shows the group is sent but the attribute name is http://schemas.xmlsoap.org/ws/2005/05/identity/claims/group (standard for Azure)

  
                                                <Attribute Name="http://schemas.xmlsoap.org/ws/2005/05/identity/claims/group">
                                                                <AttributeValue>WSS_Users</AttributeValue>
                                                </Attribute>
 

Changing the WSS group attribute name to http://schemas.xmlsoap.org/ws/2005/05/identity/claims/group triggered a match and group policies worked.