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/add-password-reset-policy.md
+23-10Lines changed: 23 additions & 10 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -9,7 +9,7 @@ manager: CelesteDG
9
9
ms.service: active-directory
10
10
ms.workload: identity
11
11
ms.topic: how-to
12
-
ms.date: 08/24/2021
12
+
ms.date: 10/07/2022
13
13
ms.custom: project-no-code
14
14
ms.author: kengaderdus
15
15
ms.subservice: B2C
@@ -114,6 +114,7 @@ Declare your claims in the [claims schema](claimsschema.md). Open the extensions
114
114
115
115
[Page layout version](contentdefinitions.md#migrating-to-page-layout) 2.1.2 is required to enable the self-service password reset flow in the sign-up or sign-in journey. To upgrade the page layout version:
116
116
117
+
1. Open the base file of your policy, for example, *SocialAndLocalAccounts/TrustFrameworkBase.xml*.
117
118
1. Search for the [BuildingBlocks](buildingblocks.md) element. If the element doesn't exist, add it.
118
119
1. Locate the [ContentDefinitions](contentdefinitions.md) element. If the element doesn't exist, add it.
119
120
1. Modify the **DataURI** element within the **ContentDefinition** element to have the ID `api.signuporsignin`:
@@ -131,7 +132,10 @@ Declare your claims in the [claims schema](claimsschema.md). Open the extensions
131
132
```
132
133
133
134
### Add the technical profiles
134
-
A claims transformation technical profile accesses the `isForgotPassword` claim. The technical profile is referenced later. When it's invoked, it sets the value of the `isForgotPassword` claim to `true`. Find the **ClaimsProviders** element (if the element doesn't exist, create it), and then add the following claims provider:
135
+
A claims transformation technical profile accesses the `isForgotPassword` claim. The technical profile is referenced later. When it's invoked, it sets the value of the `isForgotPassword` claim to `true`.
136
+
137
+
1. Open the extensions file of your policy, for example, in *SocialAndLocalAccounts/TrustFrameworkExtensions.xml*.
138
+
1. Find the **ClaimsProviders** element (if the element doesn't exist, create it), and then add the following claims provider:
135
139
136
140
```xml
137
141
<!--
@@ -171,7 +175,8 @@ The user can now sign in, sign up, and perform password reset in your user journ
171
175
172
176
The sub journey is called from the user journey and performs the specific steps that deliver the password reset experience to the user. Use the `Call` type sub journey so that when the sub journey is finished, control is returned to the orchestration step that initiated the sub journey.
173
177
174
-
Find the **SubJourneys** element. If the element doesn't exist, add it after the **User Journeys** element. Then, add the following sub journey:
178
+
1. Open the extensions file of your policy, such as *SocialAndLocalAccounts/TrustFrameworkExtensions.xml*.
179
+
1. Find the **SubJourneys** element. If the element doesn't exist, add it after the **User Journeys** element. Then, add the following sub journey:
175
180
176
181
```xml
177
182
<!--
@@ -203,23 +208,25 @@ Next, connect the **Forgot your password?** link to the Forgot Password sub jour
203
208
204
209
If you don't have your own custom user journey that has a **CombinedSignInAndSignUp** step, complete the following steps to duplicate an existing sign-up or sign-in user journey. Otherwise, continue to the next section.
205
210
206
-
1. In the starter pack, open the *TrustFrameworkBase.xml* file.
211
+
1. In the starter pack, open the *TrustFrameworkBase.xml* file such as *SocialAndLocalAccounts/TrustFrameworkBase.xml*.
207
212
1. Find and copy the entire contents of the **UserJourney** element that includes `Id="SignUpOrSignIn"`.
208
-
1. Open *TrustFrameworkExtensions.xml* and find the **UserJourneys** element. If the element doesn't exist, add one.
213
+
1. Open *TrustFrameworkExtensions.xml*file, such as *SocialAndLocalAccounts/TrustFrameworkExtensions.xml*, and find the **UserJourneys** element. If the element doesn't exist, create it.
209
214
1. Create a child element of the **UserJourneys** element by pasting the entire contents of the **UserJourney** element you copied in step 2.
210
215
1. Rename the ID of the user journey. For example, `Id="CustomSignUpSignIn"`.
211
216
212
217
### Connect the Forgot Password link to the Forgot Password sub journey
213
218
214
-
In your user journey, you can represent the Forgot Password sub journey as a **ClaimsProviderSelection**. Adding this element connects the **Forgot your password?** link to the Forgot Password sub journey.
219
+
In your user journey, you can represent the Forgot Password sub journey as a **ClaimsProviderSelection**. By adding this element, you connect the **Forgot your password?** link to the Forgot Password sub journey.
220
+
221
+
1. Open the *TrustFrameworkExtensions.xml* file, such as *SocialAndLocalAccounts/TrustFrameworkExtensions.xml*.
215
222
216
223
1. In the user journey, find the orchestration step element that includes `Type="CombinedSignInAndSignUp"` or `Type="ClaimsProviderSelection"`. It's usually the first orchestration step. The **ClaimsProviderSelections** element contains a list of identity providers that a user can use to sign in. Add the following line:
@@ -245,7 +252,13 @@ In your user journey, you can represent the Forgot Password sub journey as a **C
245
252
246
253
### Set the user journey to be executed
247
254
248
-
Now that you've modified or created a user journey, in the **Relying Party** section, specify the journey that Azure AD B2C will execute for this custom policy. In the [RelyingParty](relyingparty.md) element, find the **DefaultUserJourney** element. Update the **DefaultUserJourney ReferenceId** to match the ID of the user journey in which you added the **ClaimsProviderSelections**.
255
+
Now that you've modified or created a user journey, in the **Relying Party** section, specify the journey that Azure AD B2C will execute for this custom policy.
256
+
257
+
1. Open the file that has the **Relying Party** element, such as *SocialAndLocalAccounts/SignUpOrSignin.xml*.
258
+
259
+
1. In the [RelyingParty](relyingparty.md) element, find the **DefaultUserJourney** element.
260
+
261
+
1. Update the **DefaultUserJourney ReferenceId** to match the ID of the user journey in which you added the **ClaimsProviderSelections**.
249
262
250
263
```xml
251
264
<RelyingParty>
@@ -275,8 +288,8 @@ Your application might need to detect whether the user signed in by using the Fo
275
288
1. In the Azure portal, search for and select **Azure AD B2C**.
276
289
1. In the menu under **Policies**, select **Identity Experience Framework**.
277
290
1. Select **Upload custom policy**. In the following order, upload the two policy files that you changed:
278
-
1. The extension policy, for example, *TrustFrameworkExtensions.xml*.
279
-
1. The relying party policy, for example, *SignUpSignIn.xml*.
291
+
1. The extension policy, for example, *SocialAndLocalAccounts/TrustFrameworkExtensions.xml*.
292
+
1. The relying party policy, for example, *SocialAndLocalAccounts/SignUpOrSignin.xml*.
Copy file name to clipboardExpand all lines: articles/active-directory-b2c/application-types.md
+3-3Lines changed: 3 additions & 3 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -9,7 +9,7 @@ manager: CelesteDG
9
9
ms.service: active-directory
10
10
ms.workload: identity
11
11
ms.topic: conceptual
12
-
ms.date: 08/10/2022
12
+
ms.date: 10/11/2022
13
13
ms.author: kengaderdus
14
14
ms.subservice: B2C
15
15
@@ -38,7 +38,7 @@ These steps can differ slightly based on the type of application you're building
38
38
39
39
## Web applications
40
40
41
-
For web applications (including .NET, PHP, Java, Ruby, Python, and Node.js) that are hosted on a server and accessed through a browser, Azure AD B2C supports [OpenID Connect](protocols-overview.md) for all user experiences. In the Azure AD B2C implementation of OpenID Connect, your web application initiates user experiences by issuing authentication requests to Azure AD. The result of the request is an `id_token`. This security token represents the user's identity. It also provides information about the user in the form of claims:
41
+
For web applications (including .NET, PHP, Java, Ruby, Python, and Node.js) that are hosted on a web server and accessed through a browser, Azure AD B2C supports [OpenID Connect](protocols-overview.md) for all user experiences. In the Azure AD B2C implementation of OpenID Connect, your web application initiates user experiences by issuing authentication requests to Azure AD. The result of the request is an `id_token`. This security token represents the user's identity. It also provides information about the user in the form of claims:
42
42
43
43
```json
44
44
// Partial raw id_token
@@ -69,7 +69,7 @@ Validation of the `id_token` by using a public signing key that is received from
69
69
70
70
To see this scenario in action, try one of the web application sign-in code samples in our [Getting started section](overview.md).
71
71
72
-
In addition to facilitating simple sign in, a web server application might also need to access a back-end web service. In this case, the web application can perform a slightly different [OpenID Connect flow](openid-connect.md) and acquire tokens by using authorization codes and refresh tokens. This scenario is depicted in the following [Web APIs section](#web-apis).
72
+
In addition to facilitating simple sign in, a web application might also need to access a back-end web service. In this case, the web application can perform a slightly different [OpenID Connect flow](openid-connect.md) and acquire tokens by using authorization codes and refresh tokens. This scenario is depicted in the following [Web APIs section](#web-apis).
0 commit comments