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/active-directory-b2c-reference-oidc.md
+1Lines changed: 1 addition & 0 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -271,6 +271,7 @@ GET https://{tenant}.b2clogin.com/{tenant}.onmicrosoft.com/{policy}/oauth2/v2.0/
271
271
| {tenant} | Yes | Name of your Azure AD B2C tenant |
272
272
| {policy} | Yes | The user flow that you want to use to sign the user out of your application. |
273
273
| id_token_hint| No | A previously issued ID token to pass to the logout endpoint as a hint about the end user's current authenticated session with the client. The `id_token_hint` ensures that the `post_logout_redirect_uri` is a registered reply URL in your Azure AD B2C application settings. |
274
+
| client_id | No*| The application ID that the [Azure portal](https://portal.azure.com/) assigned to your application.<br><br>\**This is required when using `Application` isolation SSO configuration and _Require ID Token_ in logout request is set to `No`.*|
274
275
| post_logout_redirect_uri | No | The URL that the user should be redirected to after successful sign out. If it isn't included, Azure AD B2C shows the user a generic message. Unless you provide an `id_token_hint`, you should not register this URL as a reply URL in your Azure AD B2C application settings. |
275
276
| state | No | If a `state` parameter is included in the request, the same value should appear in the response. The application should verify that the `state` values in the request and response are identical. |
Copy file name to clipboardExpand all lines: articles/active-directory-b2c/connect-with-saml-service-providers.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
@@ -160,7 +160,7 @@ Now that your tenant can issue SAML assertions, you need to create the SAML rely
160
160
161
161
1. Open the *SignUpOrSigninSAML.xml* file in your preferred editor.
162
162
163
-
1. Change the `PolicyId` and `PublicPolicyUri` of the policy to _B2C_1A_signup_signin_saml_ and _http://tenant-name.onmicrosoft.com/B2C_1A_signup_signin_saml_ as seen below.
163
+
1. Change the `PolicyId` and `PublicPolicyUri` of the policy to _B2C_1A_signup_signin_saml_ and `http://tenant-name.onmicrosoft.com/B2C_1A_signup_signin_saml` as seen below.
Copy file name to clipboardExpand all lines: articles/active-directory-b2c/custom-email.md
+87-74Lines changed: 87 additions & 74 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -147,13 +147,14 @@ With a SendGrid account created and SendGrid API key stored in a Azure AD B2C po
147
147
</html>
148
148
```
149
149
150
+
1. Expand **Settings** on the left, and for **Email Subject**, enter `{{subject}}`.
150
151
1. Select **Save Template**.
151
152
1. Return to the **Transactional Templates** page by selecting the back arrow.
152
153
1. Record the **ID** of template you created for use in a later step. For example, `d-989077fbba9746e89f3f6411f596fb96`. You specify this ID when you [add the claims transformation](#add-the-claims-transformation).
153
154
154
155
## Add Azure AD B2C claim types
155
156
156
-
In your policy, add the following claim types.
157
+
In your policy, add the following claim types to the `<ClaimsSchema>` element within `<BuildingBlocks>`.
157
158
158
159
These claims types are necessary to generate and verify the email address using a one-time password (OTP) code.
159
160
@@ -174,6 +175,50 @@ These claims types are necessary to generate and verify the email address using
174
175
</ClaimType>
175
176
```
176
177
178
+
## Add the claims transformation
179
+
180
+
Next, you need a claims transformation to output a JSON string claim that will be the body of the request sent to SendGrid.
181
+
182
+
The JSON object's structure is defined by the IDs in dot notation of the InputParameters and the TransformationClaimTypes of the InputClaims. Numbers in the dot notation imply arrays. The values come from the InputClaims' values and the InputParameters' "Value" properties. For more information about JSON claims transformations, see [JSON claims transformations](json-transformations.md).
183
+
184
+
Add the following claims transformation to the `<ClaimsTransformations>` element within `<BuildingBlocks>`. Make the following updates to the claims transformation XML:
185
+
186
+
* Update the `template_id` InputParameter value with the ID of the SendGrid transactional template you created earlier in [Create SendGrid template](#create-sendgrid-template).
187
+
* Update the `from.email` address value. Use a valid email address to help prevent the verification email from being marked as spam.
188
+
* Update the value of the `personalizations.0.dynamic_template_data.subject` subject line input parameter with a subject line appropriate for your organization.
Below the claims transformations within `<BuildingBlocks>`, add the following [ContentDefinition](contentdefinitions.md) to reference the version 2.0.0 data URI:
Under [ClaimsSchema](claimsschema.md), add the following [DisplayControl](display-controls.md) of type [VerificationControl](display-control-verification.md) to your policy.
235
+
Under content definitions, still within `<BuildingBlocks>`, add the following [DisplayControl](display-controls.md) of type [VerificationControl](display-control-verification.md) to your policy.
191
236
192
237
```XML
193
238
<DisplayControls>
@@ -220,6 +265,8 @@ Under [ClaimsSchema](claimsschema.md), add the following [DisplayControl](displa
220
265
221
266
The `GenerateOtp` technical profile generates a code for the email address. The `VerifyOtp` technical profile verifies the code associated with the email address. You can change the configuration of the format and the expiration of the one-time password. For more information about OTP technical profiles, see [Define a one-time password technical profile](one-time-password-technical-profile.md).
222
267
268
+
Add the following technical profiles to the `<ClaimsProviders>` element.
269
+
223
270
```XML
224
271
<ClaimsProvider>
225
272
<DisplayName>One time password technical profiles</DisplayName>
@@ -266,6 +313,8 @@ The `GenerateOtp` technical profile generates a code for the email address. The
266
313
267
314
This REST API technical profile generates the email content (using the SendGrid format). For more information about RESTful technical profiles, see [Define a RESTful technical profile](restful-technical-profile.md).
268
315
316
+
As with the OTP technical profiles, add the following technical profiles to the `<ClaimsProviders>` element.
317
+
269
318
```XML
270
319
<ClaimsProvider>
271
320
<DisplayName>RestfulProvider</DisplayName>
@@ -293,85 +342,49 @@ This REST API technical profile generates the email content (using the SendGrid
293
342
</ClaimsProvider>
294
343
```
295
344
296
-
## Add the claims transformation
297
-
298
-
Add the following claims transformation to output a JSON string claim that will be the body of the request sent to SendGrid. Make the following updates to the claims transformation XML:
299
-
300
-
* Update the `template_id` InputParameter value with the ID of the SendGrid transactional template you created earlier in [Create SendGrid template](#create-sendgrid-template).
301
-
* Update the value of the `personalizations.0.dynamic_template_data.subject` subject line input parameter with a subject line appropriate for your organization.
302
-
303
-
The JSON object's structure is defined by the IDs in dot notation of the InputParameters and the TransformationClaimTypes of the InputClaims. Numbers in the dot notation imply arrays. The values come from the InputClaims' values and the InputParameters' "Value" properties. For more information about JSON claims transformations, see [JSON claims transformations](json-transformations.md).
In the final step, add a reference to the DisplayControl you created. Replace your existing `LocalAccountSignUpWithLogonEmail` self-asserted technical profile with the following if you used an earlier version of Azure AD B2C policy. This technical profile uses `DisplayClaims` with a reference to the DisplayControl.
340
348
341
349
For more information, see [Self-asserted technical profile](restful-technical-profile.md) and [DisplayControl](display-controls.md).
Copy file name to clipboardExpand all lines: articles/active-directory-domain-services/network-considerations.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
# Virtual network design considerations and configuration options for Azure AD Domain Services
18
18
19
-
As Azure Active Directory Domain Services (AD DS) provides authentication and management services to other applications and workloads, network connectivity is a key component. Without appropriately configured virtual network resources, applications and workloads can't communicate with and use the features provides by Azure AD DS. If you plan your virtual network correctly, you make sure that Azure AD DS can serve your applications and workloads as needed.
19
+
As Azure Active Directory Domain Services (AD DS) provides authentication and management services to other applications and workloads, network connectivity is a key component. Without appropriately configured virtual network resources, applications and workloads can't communicate with and use the features provided by Azure AD DS. If you plan your virtual network correctly, you make sure that Azure AD DS can serve your applications and workloads as needed.
20
20
21
21
This article outlines design considerations and requirements for an Azure virtual network that supports Azure AD DS.
0 commit comments