search cancel

Users getting blocked accessing valid resources after enabling SAML authentication via Azure SAML IDP server


Article ID: 229700


Updated On:


Cloud Secure Web Gateway - Cloud SWG


Users running WSS agent and accessing resources without issues

Switched WSS agent authentication to SAML for testing and same users were blocked from accessing valid resources 

Block messages showed valid user data so assumption is that group information was missing

SAML integration with Azure SAML ISP server as per Broadcom documentation


WSS agent

Azure SAML IDP server 

Azure AD Connect synchronising on premise AD users into Azure


Azure IDP server sending SAML assertion with group attribute containing GUIDs and not logical group names


Add group claims within Azure SAML IDP server using options below that adds the Active Directory attributes synced from Active Directory instead of Azure AD objectIDs. In our case, we selected the 'NetBIOSDomain\sAMAccountName' format from the drop-down so that the info passed in matched the Group names within WSS configuration.


Additional Information

We can see that the proxy does not seem to get any group information based on the HTTP log entry for that user – we see the user (yellow) but the group entry is missing (red)

2021-10-26 10:11:28 "DP4-GGBLO11_proxysg3" 132 [email protected] - - OBSERVED "Technology/Internet;BCOM Bypass High Risk Exes and Archives" - 200 TCP_NC_MISS GET text/html http 80 / - - "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/95.0.4638.54 Safari/537.36 Edg/95.0.1020.30" 1472 481 - - - - 0 "client" client_connector "Symantec Web Security Service" "none" "United States" - - - - - none - - - - none - - ICAP_NOT_SCANNED - ICAP_NOT_SCANNED - "United States" - "United Kingdom" 2 - - - - - - - - - - - - - - - - 0c1121139bde6b9f-000000003903bb01-000000006177d450 "GB"

With the HAR file, we can extract the assertion sent to BCSAMLPOST endpoint … we do see the group attribute but we also see the group values sent are GUIDs and not the group names. (see red below)

                                                <NameID Format="urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress">[email protected]</NameID>
                                                <SubjectConfirmation Method="urn:oasis:names:tc:SAML:2.0:cm:bearer">
                                                                <SubjectConfirmationData InResponseTo="_30c8483d04d4cb90c8f1a78e334aec96c61b27ca206a1bd3316a629c4ba50ad5" NotOnOrAfter="2021-10-26T11:14:41.799Z" Recipient=""/>
                                <Conditions NotBefore="2021-10-26T10:09:41.799Z" NotOnOrAfter="2021-10-26T11:14:41.799Z">
                                                <Attribute Name="">
                                <AuthnStatement AuthnInstant="2021-10-26T06:56:32.285Z" SessionIndex="_95a2be1e-f209-48d7-a285-a8e20e63a000">
                </Assertion> includes good information from Azure side.