X-ms-cpim

0 views

Skip to first unread message

Paulette Dzurilla

unread,

Aug 3, 2024, 4:43:17 PM8/3/24

to untozuba

To safeguard access to sites, web browsers will introduce a new secure-by-default model that assumes all cookies should be protected from external access unless otherwise specified. The Chrome browser is the first to implement this change, starting with Chrome 80 in February 2020. For more information about preparing for the change in Chrome, see Developers: Get Ready for New SameSite=None; Secure Cookie Settings on the Chromium Blog.

Developers must use the new cookie setting, SameSite=None, to designate cookies for cross-site access. When the SameSite=None attribute is present, an additional Secure attribute must be used so cross-site cookies can only be accessed over HTTPS connections. Validate and test all your applications, including those applications that use Azure AD B2C.

To prevent Cross Site Request Forgery (CSRF) attacks, Azure AD B2C applies the Synchronizer Token strategy mechanism. For more details on this pattern, check out the Cross-Site Request Forgery Prevention article.

Azure AD B2C generates a synchronizer token, and adds it in two places; in a cookie labeled x-ms-cpim-csrf, and a query string parameter named csrf_token in the URL of the page sent to the Azure AD B2C. As Azure AD B2C service processes the incoming requests from the browser, it confirms that both the query string and cookie versions of the token exist, and that they exactly match. Also it verifies the elements of the contents of the token to confirm against expected values for the in-progress authentication.

For example, in the sign-up or sign-in page, when a user selects the "Forgot password", or "Sign-up now" links, the browser sends a GET request to Azure AD B2C in order to load the contents of the next page. The request to load content Azure AD B2C additionally chooses to send and validate the Synchronizer Token as an extra layer of protection to ensure that the request to load the page was the result of an in-progress authentication.

My custom policies have a journey step in which additional information of the user is validated against an API. When this validation fails an error is thrown and the JWT token is not issued for that user journey. This user journey works, but has issues with SSO:

What happens in the latter case is that the sso (x-ms-cpim-sso) cookie is removed, too, and the user is in fact signed out from all applications, also from application A and SSO is not working anymore. The user has to sign into application A again.

I tried changing the underlying technical profile from using Web.TPEngine.SSO.NoopSSOSessionProvider to Web.TPEngine.SSO.DefaultSSOSessionProvider, but then the user is signed into application B without any validation errors, while he should not be signed in.

Is there any way to control this behaviour, such that the user keeps signed in with B2C after successfully signing in to application A, but is not issued a token for application B when one of the policies fail to execute normally?

This setting allows you to maintain a user session exclusively for anapplication, independent of other applications. For example, you canuse this setting if you want the user to sign in to Contoso Pharmacyregardless of whether the user is already signed into ContosoGroceries.