You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: articles/active-directory-b2c/customize-ui-overview.md
+2Lines changed: 2 additions & 0 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -62,6 +62,8 @@ When you choose a template, the selected layout is applied to all pages in your
62
62
63
63
## Custom HTML and CSS
64
64
65
+
If you wish to design your own policy layout with your customized HTML and CSS, you can do so by switching the "Use custom page content" toggle for each of the Layout names present in your policy. Please follow the below instructions regarding the custom layout configurations:
66
+
65
67
Azure AD B2C runs code in your customer's browser by using an approach called [Cross-Origin Resource Sharing (CORS)](https://www.w3.org/TR/cors/).
66
68
67
69
At runtime, content is loaded from a URL that you specify in your user flow or custom policy. Each page in the user experience loads its content from the URL you specify for that page. After content is loaded from your URL, it's merged with an HTML fragment inserted by Azure AD B2C, and then the page is displayed to your customer.
Copy file name to clipboardExpand all lines: articles/active-directory-b2c/technicalprofiles.md
+1-1Lines changed: 1 addition & 1 deletion
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -95,7 +95,7 @@ The **TechnicalProfile** contains the following elements:
95
95
| OutputClaimsTransformations | 0:1 | A list of previously defined references to claims transformations that should be executed after the claims are received from the claims provider. |
96
96
| ValidationTechnicalProfiles | 0:n| A list of references to other technical profiles that the technical profile uses for validation purposes. For more information, see [validation technical profile](validation-technical-profile.md)|
97
97
| SubjectNamingInfo | 0:1 | Controls the production of the subject name in tokens where the subject name is specified separately from claims. For example, OAuth or SAML. |
98
-
| IncludeInSso | 0:1 | Whether usage of this technical profile should apply single sign-on (SSO) behavior for the session, or instead require explicit interaction. Possible values: `true` (default), or `false`. |
98
+
| IncludeInSso | 0:1 | Whether usage of this technical profile should apply single sign-on (SSO) behavior for the session, or instead require explicit interaction. This element is valid only in SelfAsserted profiles used within a Validation technical profile. Possible values: `true` (default), or `false`. |
99
99
| IncludeClaimsFromTechnicalProfile | 0:1 | An identifier of a technical profile from which you want all of the input and output claims to be added to this technical profile. The referenced technical profile must be defined in the same policy file. |
100
100
| IncludeTechnicalProfile |0:1 | An identifier of a technical profile from which you want all data to be added to this technical profile. The referenced technical profile must exist in the same policy file. |
101
101
| UseTechnicalProfileForSessionManagement | 0:1 | A different technical profile to be used for session management. |
Copy file name to clipboardExpand all lines: articles/active-directory-domain-services/deploy-kcd.md
+1-1Lines changed: 1 addition & 1 deletion
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -16,7 +16,7 @@ ms.author: iainfou
16
16
---
17
17
# Configure Kerberos constrained delegation (KCD) in Azure Active Directory Domain Services
18
18
19
-
As you run applications, there may be a need for those applications to access resources in the context of a different user. Active Directory Domain Services (AD DS) supports a mechanism called *Kerberos delegation* that enables this use-case. Kerberos *constrained* delegation (KCD) then builds on this mechanism to define specific resources that can be accessed in the context of the user. Azure Active Directory Domain Services (Azure AD DS) managed domains are more securely locked down that traditional on-premises AD DS environments, so use a more secure *resource-based* KCD.
19
+
As you run applications, there may be a need for those applications to access resources in the context of a different user. Active Directory Domain Services (AD DS) supports a mechanism called *Kerberos delegation* that enables this use-case. Kerberos *constrained* delegation (KCD) then builds on this mechanism to define specific resources that can be accessed in the context of the user. Azure Active Directory Domain Services (Azure AD DS) managed domains are more securely locked down than traditional on-premises AD DS environments, so use a more secure *resource-based* KCD.
20
20
21
21
This article shows you how to configure resource-based Kerberos constrained delegation in an Azure AD DS managed domain.
title: How to handle SameSite cookie changes in Chrome browser | Azure
3
+
titleSuffix: Microsoft identity platform
4
+
description: Learn how to handle SameSite cookie changes in Chrome browser.
5
+
services: active-directory
6
+
documentationcenter: ''
7
+
author: jmprieur
8
+
manager: CelesteDG
9
+
10
+
ms.service: active-directory
11
+
ms.subservice: develop
12
+
ms.workload: identity
13
+
ms.topic: conceptual
14
+
ms.date: 01/27/2020
15
+
ms.author: jmprieur
16
+
ms.reviewer: kkrishna
17
+
ms.custom: aaddev
18
+
---
19
+
# Handle SameSite cookie changes in Chrome browser
20
+
21
+
## What is SameSite?
22
+
23
+
`SameSite` is a property that can be set in HTTP cookies to prevent Cross Site Request Forgery(CSRF) attacks in web applications:
24
+
25
+
- When `SameSite` is set to **Lax**, the cookie is sent in requests within the same site and in GET requests from other sites. It isn't sent in GET requests that are cross-domain.
26
+
- A value of **Strict** ensures that the cookie is sent in requests only within the same site.
27
+
28
+
By default, the `SameSite` value is NOT set in browsers and that's why there are no restrictions on cookies being sent in requests. An application would need to opt-in to the CSRF protection by setting **Lax** or **Strict** per their requirements.
29
+
30
+
## SameSite changes and impact on authentication
31
+
32
+
Recent [updates to the standards on SameSite](https://tools.ietf.org/html/draft-west-cookie-incrementalism-00) propose protecting apps by making the default behavior of `SameSite` when no value is set to Lax. This mitigation means cookies will be restricted on HTTP requests except GET made from other sites. Additionally, a value of **None** is introduced to remove restrictions on cookies being sent. These updates will soon be released in an upcoming version of the Chrome browser.
33
+
34
+
When web apps authenticate with the Microsoft Identity platform using the response mode "form_post", the login server responds to the application using an HTTP POST to send the tokens or auth code. Because this request is a cross-domain request (from `login.microsoftonline.com` to your domain - for instance https://contoso.com/auth), cookies that were set by your app now fall under the new rules in Chrome. The cookies that need to be used in cross-site scenarios are cookies that hold the *state* and *nonce* values, that are also sent in the login request. There are other cookies dropped by Azure AD to hold the session.
35
+
36
+
If you don't update your web apps, this new behavior will result in authentication failures.
37
+
38
+
## Mitigation and samples
39
+
40
+
To overcome the authentication failures, web apps authenticating with the Microsoft identity platform can set the `SameSite` property to `None` for cookies that are used in cross-domain scenarios when running on the Chrome browser.
41
+
Other browsers (see [here](https://www.chromium.org/updates/same-site/incompatible-clients) for a complete list) follow the previous behavior of `SameSite` and won't include the cookies if `SameSite=None` is set.
42
+
That's why, to support authentication on multiple browsers web apps will have to set the `SameSite` value to `None` only on Chrome and leave the value empty on other browsers.
43
+
44
+
This approach is demonstrated in our code samples below.
45
+
46
+
# [.NET](#tab/dotnet)
47
+
48
+
The table below presents the pull requests that worked around the SameSite changes in our ASP.NET and ASP.NET Core samples.
49
+
50
+
| Sample | Pull request |
51
+
| ------ | ------------ |
52
+
|[ASP.NET Core Web App incremental tutorial](https://github.com/Azure-Samples/active-directory-aspnetcore-webapp-openidconnect-v2)|[Same site cookie fix #261](https://github.com/Azure-Samples/active-directory-aspnetcore-webapp-openidconnect-v2/pull/261)|
53
+
|[ASP.NET MVC Web App sample](https://github.com/Azure-Samples/ms-identity-aspnet-webapp-openidconnect)|[Same site cookie fix #35](https://github.com/Azure-Samples/ms-identity-aspnet-webapp-openidconnect/pull/35)|
54
+
|[active-directory-dotnet-admin-restricted-scopes-v2](https://github.com/azure-samples/active-directory-dotnet-admin-restricted-scopes-v2)|[Same site cookie fix #28](https://github.com/Azure-Samples/active-directory-dotnet-admin-restricted-scopes-v2/pull/28)|
55
+
56
+
for details on how to handle SameSite cookies in ASP.NET and ASP.NET Core, see also:
57
+
58
+
-[Work with SameSite cookies in ASP.NET Core](https://docs.microsoft.com/aspnet/core/security/samesite) .
59
+
-[ASP.NET Blog on SameSite issue](https://devblogs.microsoft.com/aspnet/upcoming-samesite-cookie-changes-in-asp-net-and-asp-net-core/)
Copy file name to clipboardExpand all lines: articles/active-directory/develop/scenario-daemon-acquire-token.md
+34-32Lines changed: 34 additions & 32 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -16,16 +16,18 @@ ms.workload: identity
16
16
ms.date: 10/30/2019
17
17
ms.author: jmprieur
18
18
ms.custom: aaddev
19
-
#Customer intent: As an application developer, I want to know how to write a daemon app that can call web APIs using the Microsoft identity platform for developers.
19
+
20
+
#Customer intent: As an application developer, I want to know how to write a daemon app that can call web APIs by using the Microsoft identity platform for developers.
21
+
20
22
---
21
23
22
24
# Daemon app that calls web APIs - acquire a token
23
25
24
-
Once the confidential client application is constructed, you can acquire a token for the app by calling ``AcquireTokenForClient``, passing the scope, and forcing or not a refresh of the token.
26
+
After you've constructed a confidential client application, you can acquire a token for the app by calling `AcquireTokenForClient`, passing the scope, and optionally forcing a refresh of the token.
25
27
26
28
## Scopes to request
27
29
28
-
The scope to request for a client credential flow is the name of the resource followed by `/.default`. This notation tells Azure AD to use the **applicationlevel permissions** declared statically during the application registration. Also, as seen previously, these API permissions must be granted by a tenant administrator
30
+
The scope to request for a client credential flow is the name of the resource followed by `/.default`. This notation tells Azure Active Directory (Azure AD) to use the *application-level permissions* declared statically during application registration. Also, these API permissions must be granted by a tenant administrator.
29
31
30
32
# [.NET](#tab/dotnet)
31
33
@@ -36,7 +38,7 @@ var scopes = new [] { ResourceId+"/.default"};
36
38
37
39
# [Python](#tab/python)
38
40
39
-
In MSAL Python, the configuration file would look like the following code snippet:
41
+
In MSAL Python, the configuration file looks like this code snippet:
40
42
41
43
```Json
42
44
{
@@ -52,26 +54,26 @@ final static String GRAPH_DEFAULT_SCOPE = "https://graph.microsoft.com/.default"
52
54
53
55
---
54
56
55
-
### Case of Azure AD (v1.0) resources
57
+
### Azure AD (v1.0) resources
56
58
57
-
The scope used for client credentials should always be resourceId+"/.default"
59
+
The scope used for client credentials should always be the resource ID followed by `/.default`.
58
60
59
61
> [!IMPORTANT]
60
-
> For MSAL asking an access token for a resource accepting a v1.0 access token, Azure AD parses the desired audience from the requested scope by taking everything before the last slash and using it as the resource identifier.
61
-
> Therefore if, like Azure SQL (**https://database.windows.net**) the resource expects an audience ending with a slash (for Azure SQL: `https://database.windows.net/`), you'll need to request a scope of `https://database.windows.net//.default` (note the double slash). See also MSAL.NET issue [#747](https://github.com/AzureAD/microsoft-authentication-library-for-dotnet/issues/747): Resource url's trailing slash is omitted, which caused sql auth failure.
62
+
> When MSAL requests an access token for a resource that accepts a version 1.0 access token, Azure AD parses the desired audience from the requested scope by taking everything before the last slash and using it as the resource identifier.
63
+
> So if, like Azure SQL Database (**https:\//database.windows.net**), the resource expects an audience that ends with a slash (for Azure SQL Database, `https://database.windows.net/`), you'll need to request a scope of `https://database.windows.net//.default`. (Note the double slash.) See also MSAL.NET issue [#747: Resource url's trailing slash is omitted, which caused sql auth failure](https://github.com/AzureAD/microsoft-authentication-library-for-dotnet/issues/747).
62
64
63
65
## AcquireTokenForClient API
64
66
65
-
To acquire a token for the app, you'll use `AcquireTokenForClient` or the equivalent depending on the platforms.
67
+
To acquire a token for the app, you'll use `AcquireTokenForClient` or its equivalent, depending on the platform.
66
68
67
69
# [.NET](#tab/dotnet)
68
70
69
71
```csharp
70
72
usingMicrosoft.Identity.Client;
71
73
72
-
// With client credentials flows the scopes is ALWAYS of the shape "resource/.default", as the
74
+
// With client credentials flows, the scope is always of the shape "resource/.default" because the
73
75
// application permissions need to be set statically (in the portal or by PowerShell), and then granted by
// The application does not have sufficient permissions
86
-
// - did you declare enough app permissions in during the app creation?
87
-
// - did the tenant admin needs to grant permissions to the application.
87
+
// The application doesn't have sufficient permissions.
88
+
// - Did you declare enough app permissions during app creation?
89
+
// - Did the tenant admin grant permissions to the application?
88
90
}
89
91
catch (MsalServiceExceptionex) when (ex.Message.Contains("AADSTS70011"))
90
92
{
91
-
// Invalid scope. The scope has to be of the form "https://resourceurl/.default"
92
-
// Mitigation: change the scope to be as expected !
93
+
// Invalid scope. The scope has to be in the form "https://resourceurl/.default"
94
+
// Mitigation: Change the scope to be as expected.
93
95
}
94
96
```
95
97
@@ -99,27 +101,27 @@ catch (MsalServiceException ex) when (ex.Message.Contains("AADSTS70011"))
99
101
# The pattern to acquire a token looks like this.
100
102
result =None
101
103
102
-
#Firstly, looks up a token from cache
103
-
#Since we are looking for token for the current app, NOT for an end user,
104
-
#notice we give account parameter as None.
104
+
#First, the code looks up a token from the cache.
105
+
#Because we're looking for a token for the current app, not for a user,
106
+
#use None for the account parameter.
105
107
result = app.acquire_token_silent(config["scope"], account=None)
106
108
107
109
ifnot result:
108
110
logging.info("No suitable token exists in cache. Let's get a new one from AAD.")
109
111
result = app.acquire_token_for_client(scopes=config["scope"])
110
112
111
113
if"access_token"in result:
112
-
# Call a protected API with the access token
114
+
# Call a protected API with the access token.
113
115
print(result["token_type"])
114
116
else:
115
117
print(result.get("error"))
116
118
print(result.get("error_description"))
117
-
print(result.get("correlation_id")) # You may need this when reporting a bug
119
+
print(result.get("correlation_id")) # You might need this when reporting a bug.
118
120
```
119
121
120
122
# [Java](#tab/java)
121
123
122
-
This is an extract from the [MSAL Java dev samples](https://github.com/AzureAD/microsoft-authentication-library-for-java/blob/dev/src/samples/confidential-client/).
124
+
This code is extracted from the [MSAL Java dev samples](https://github.com/AzureAD/microsoft-authentication-library-for-java/blob/dev/src/samples/confidential-client/).
#### Second case: Access token request with a certificate
166
+
#### Second case: Access the token request by using a certificate
165
167
166
168
```Text
167
-
POST /{tenant}/oauth2/v2.0/token HTTP/1.1 // Line breaks for clarity
169
+
POST /{tenant}/oauth2/v2.0/token HTTP/1.1 // Line breaks for clarity.
168
170
Host: login.microsoftonline.com
169
171
Content-Type: application/x-www-form-urlencoded
170
172
@@ -179,8 +181,8 @@ For more information, see the protocol documentation: [Microsoft identity platfo
179
181
180
182
## Application token cache
181
183
182
-
In MSAL.NET, `AcquireTokenForClient` uses the **application token cache** (All the other AcquireTokenXX methods use the user token cache)
183
-
Don't call `AcquireTokenSilent` before calling `AcquireTokenForClient` as`AcquireTokenSilent` uses the **user** token cache. `AcquireTokenForClient` checks the **application** token cache itself and updates it.
184
+
In MSAL.NET, `AcquireTokenForClient` uses the application token cache. (All the other AcquireToken*XX* methods use the user token cache.)
185
+
Don't call `AcquireTokenSilent` before you call `AcquireTokenForClient`, because`AcquireTokenSilent` uses the *user* token cache. `AcquireTokenForClient` checks the *application* token cache itself and updates it.
184
186
185
187
## Troubleshooting
186
188
@@ -190,8 +192,8 @@ If you get an error message telling you that you used an invalid scope, you prob
190
192
191
193
### Did you forget to provide admin consent? Daemon apps need it!
192
194
193
-
If you get an error when calling the API **Insufficient privileges to complete the operation**, the tenant administrator needs to grant permissions to the application. See step 6 of Register the client app above.
194
-
You'll typically see and error like the following error description:
195
+
If you get an **Insufficient privileges to complete the operation** error when you call the API, the tenant administrator needs to grant permissions to the application. See step 6 of Register the client app above.
196
+
You'll typically see an error that looks like this error:
0 commit comments