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
In Azure Active Directory B2C (Azure AD B2C), the following options are supported:
24
-
25
-
-**Native Client**: User interaction during authentication happens when code runs on a user-side device. The device can be a mobile application that's running in a native operating system, such as Android and iOS.
26
-
-**Public client flow**: Only user credentials, gathered by an application, are sent in the API call. The credentials of the application are not sent.
27
-
-**Add new claims**: The ID token contents can be changed to add new claims.
28
-
29
-
The following flows are not supported:
30
-
31
-
-**Server-to-server**: The identity protection system needs a reliable IP address gathered from the caller (the native client) as part of the interaction. In a server-side API call, only the server’s IP address is used. If a dynamic threshold of failed authentications is exceeded, the identity protection system may identify a repeated IP address as an attacker.
32
-
-**Confidential client flow**: The application client ID is validated, but the application secret is not validated.
@@ -25,158 +25,84 @@ Users should not enable this option on public computers.
25
25
26
26
## Prerequisites
27
27
28
-
An Azure AD B2C tenant that is configured to allow local account sign-in. KMSI is unsupported for external identity provider accounts.
28
+
- An Azure AD B2C tenant that is configured to allow local account sign-in. KMSI is unsupported for external identity provider accounts.
29
+
- Complete the steps in [Get started with custom policies](custom-policy-get-started.md).
29
30
30
-
If you don't have a tenant, you can create one using the steps in [Tutorial: Create an Azure Active Directory B2C tenant](tutorial-create-tenant.md).
31
+
## Configure the page identifier
31
32
32
-
## Add a content definition element
33
+
To enable KMSI, set the content definition `DataUri`element to [page identifier](contentdefinitions.md#datauri)`unifiedssp` and [page version](page-layout.md)*1.1.0* or above.
33
34
34
-
Under the **BuildingBlocks** element of your extension file, add a **ContentDefinitions** element.
35
+
1. Open the extension file of your policy. For example, <em>`SocialAndLocalAccounts/`**`TrustFrameworkExtensions.xml`**</em>. This extension file is one of the policy files included in the custom policy starter pack, which you should have obtained in the prerequisite, [Get started with custom policies](custom-policy-get-started.md).
36
+
1. Search for the **BuildingBlocks** element. If the element doesn't exist, add it.
37
+
1. Add the **ContentDefinitions** element to the **BuildingBlocks** element of the policy.
35
38
36
-
1. Under the **ContentDefinitions** element, add a **ContentDefinition** element with an identifier of `api.signuporsigninwithkmsi`.
37
-
2. Under the **ContentDefinition** element, add the **LoadUri**, **RecoveryUri**, and **DataUri** elements. The `urn:com:microsoft:aad:b2c:elements:unifiedssp:1.1.0` value of the **DataUri** element is a machine understandable identifier that brings up a KMSI check box in the sign-in pages. This value must not be changed.
39
+
Your custom policy should look like the following code snippet:
## Add a sign-in claims provider for a local account
55
-
56
-
You can define local account sign-in as a claims provider using the **ClaimsProvider** element in the extension file of your policy:
57
-
58
-
1. Open the *TrustFrameworkExtensions.xml* file from your working directory.
59
-
2. Find the **ClaimsProviders** element. If it doesn't exist, add it under the root element. The [starter pack](https://github.com/Azure-Samples/active-directory-b2c-custom-policy-starterpack/archive/master.zip) includes a local account sign-in claims provider.
60
-
3. Add a **ClaimsProvider** element with the **DisplayName** and **TechnicalProfile** as shown in the following example:
### Add the application identifiers to your custom policy
83
-
84
-
Add the application identifiers to the *TrustFrameworkExtensions.xml* file.
85
-
86
-
1. In the *TrustFrameworkExtensions.xml* file, find the **TechnicalProfile** element with the identifier of `login-NonInteractive` and the **TechnicalProfile** element with an identifier of `login-NonInteractive-PasswordChange` and replace all values of `IdentityExperienceFrameworkAppId` with the application identifier of the Identity Experience Framework application as described in [Getting started](custom-policy-get-started.md).
2. Replace all values of `ProxyIdentityExperienceFrameworkAppId` with the application identifier of the Proxy Identity Experience Framework application as described in [Getting started](custom-policy-get-started.md).
93
-
3. Save the extensions file.
94
-
95
-
## Create a KMSI enabled user journey
96
53
97
-
Add the sign-in claims provider for a local account to your user journey.
98
54
99
-
1. Open the base file of your policy. For example, *TrustFrameworkBase.xml*.
100
-
2. Find the **UserJourneys** element and copy the entire contents of the **UserJourney** element that uses the identifier of `SignUpOrSignIn`.
101
-
3. Open the extension file. For example, *TrustFrameworkExtensions.xml* and find the **UserJourneys** element. If the element doesn't exist, add one.
102
-
4. Paste the entire **UserJourney** element that you copied as a child of the **UserJourneys** element.
103
-
5. Change the value of the identifier for the new user journey. For example, `SignUpOrSignInWithKmsi`.
104
-
6. Finally, in the first orchestration step change the value of **ContentDefinitionReferenceId** to `api.signuporsigninwithkmsi`. The setting of this value enables the checkbox in the user journey.
105
-
7. Save and upload the extension file and make sure that all validations succeed.
Update the relying party (RP) file that initiates the user journey that you created.
146
58
147
-
1. Make a copy of *SignUpOrSignIn.xml* file in your working directory, and then rename it. For example, *SignUpOrSignInWithKmsi.xml*.
148
-
2. Open the new file and update the **PolicyId** attribute for the **TrustFrameworkPolicy** with a unique value. This is the name of your policy. For example, `SignUpOrSignInWithKmsi`.
149
-
3. Change the **ReferenceId** attribute for the **DefaultUserJourney** element to match the identifier of the new user journey that you created. For example, `SignUpOrSignInWithKmsi`.
150
-
151
-
KMSI is configured using the **UserJourneyBehaviors** element with **SingleSignOn**, **SessionExpiryType**, and **SessionExpiryInSeconds** as its first child elements. The **KeepAliveInDays** attribute controls how long the user remains signed in. In the following example, the KMSI session automatically expires after `7` days regardless of how often the user performs silent authentication. Setting the **KeepAliveInDays** value to `0` turns off KMSI functionality. By default, this value is `0`. If the value of **SessionExpiryType** is `Rolling`, the KMSI session is extended by `7` days every time the user performs silent authentication. If `Rolling` is selected, you should keep the number of days to minimum.
152
-
153
-
The value of **SessionExpiryInSeconds** represents the expiry time of an SSO session. This is used internally by Azure AD B2C to check whether the session for KMSI is expired or not. The value of **KeepAliveInDays** determines the Expires/Max-Age value of the SSO cookie in the web browser. Unlike **SessionExpiryInSeconds**, **KeepAliveInDays** is used to prevent the browser from clearing the cookie when it's closed. A user can silently sign in only if the SSO session cookie exists, which is controlled by **KeepAliveInDays**, and isn't expired, which is controlled by **SessionExpiryInSeconds**.
154
-
155
-
If a user doesn't enable **Keep me signed in** on the sign-up and sign-in page, a session expires after the time indicated by **SessionExpiryInSeconds** has passed or the browser is closed. If a user enables **Keep me signed in**, the value of **KeepAliveInDays** overrides the value of **SessionExpiryInSeconds** and dictates the session expiry time. Even if users close the browser and open it again, they can still silently sign-in as long as it's within the time of **KeepAliveInDays**. It is recommended that you set the value of **SessionExpiryInSeconds** to be a short period (1200 seconds), while the value of **KeepAliveInDays** can be set to a relatively long period (7 days), as shown in the following example:
59
+
1. Open your custom policy file. For example, *SignUpOrSignin.xml*.
60
+
1. If it doesn't already exist, add a `<UserJourneyBehaviors>` child node to the `<RelyingParty>` node. It must be located immediately after `<DefaultUserJourneyReferenceId="User journey Id" />`, for example: `<DefaultUserJourneyReferenceId="SignUpOrSignIn" />`.
61
+
1. Add the following node as a child of the `<UserJourneyBehaviors>` element.
- **SessionExpiryType** - Indicates how the session is extended by the time specified in `SessionExpiryInSeconds` and KeepAliveInDays. The `Rolling` value (default) indicates that the session is extended every time the user performs authentication. The `Absolute` value indicates that the user is forced to reauthenticate after the time period specified.
72
+
73
+
- **SessionExpiryInSeconds** - The lifetime of session cookies when *keep me signed in* is not enabled, or if a user does not select *keep me signed in*. The session expires after `SessionExpiryInSeconds` has passed, or the browser is closed.
74
+
75
+
- **KeepAliveInDays** - The lifetime of session cookies when *keep me signed* in is enabled and the user selects *keep me signed in*. The value of `KeepAliveInDays` takes precedence over the `SessionExpiryInSeconds` value, and dictates the session expiry time. If a user closes the browser and reopens it later, they can still silently sign-in as long as it's within the KeepAliveInDays time period.
76
+
77
+
For more information, see [user journey behaviors](relyingparty.md#userjourneybehaviors).
78
+
79
+
We recommend that you set the value of SessionExpiryInSeconds to be a short period (1200 seconds), while the value of KeepAliveInDays can be set to a relatively long period (30 days), as shown in the following example:
0 commit comments