Skip to content

Commit 89db4b0

Browse files
authored
Merge pull request #105785 from yoelhor/patch-30
Update custom-policy-keep-me-signed-in.md
2 parents b756dfe + 7f18820 commit 89db4b0

File tree

1 file changed

+57
-131
lines changed

1 file changed

+57
-131
lines changed

articles/active-directory-b2c/custom-policy-keep-me-signed-in.md

Lines changed: 57 additions & 131 deletions
Original file line numberDiff line numberDiff line change
@@ -8,7 +8,7 @@ manager: celestedg
88
ms.service: active-directory
99
ms.workload: identity
1010
ms.topic: conceptual
11-
ms.date: 08/29/2019
11+
ms.date: 02/27/2020
1212
ms.author: marsma
1313
ms.subservice: B2C
1414
---
@@ -25,158 +25,84 @@ Users should not enable this option on public computers.
2525

2626
## Prerequisites
2727

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).
2930

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
3132

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.
3334

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.
3538

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:
3840

39-
```XML
41+
```xml
4042
<BuildingBlocks>
4143
<ContentDefinitions>
42-
<ContentDefinition Id="api.signuporsigninwithkmsi">
43-
<LoadUri>~/tenant/default/unified.cshtml</LoadUri>
44-
<RecoveryUri>~/common/default_page_error.html</RecoveryUri>
44+
<ContentDefinition Id="api.signuporsignin">
4545
<DataUri>urn:com:microsoft:aad:b2c:elements:unifiedssp:1.1.0</DataUri>
46-
<Metadata>
47-
<Item Key="DisplayName">Signin and Signup</Item>
48-
</Metadata>
4946
</ContentDefinition>
5047
</ContentDefinitions>
5148
</BuildingBlocks>
5249
```
50+
51+
1. Save the extensions file.
5352

54-
## 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:
61-
62-
```XML
63-
<ClaimsProviders>
64-
<ClaimsProvider>
65-
<DisplayName>Local Account SignIn</DisplayName>
66-
<TechnicalProfiles>
67-
<TechnicalProfile Id="login-NonInteractive">
68-
<Metadata>
69-
<Item Key="client_id">ProxyIdentityExperienceFrameworkAppId</Item>
70-
<Item Key="IdTokenAudience">IdentityExperienceFrameworkAppId</Item>
71-
</Metadata>
72-
<InputClaims>
73-
<InputClaim ClaimTypeReferenceId="client_id" DefaultValue="ProxyIdentityExperienceFrameworkAppID" />
74-
<InputClaim ClaimTypeReferenceId="resource_id" PartnerClaimType="resource" DefaultValue="IdentityExperienceFrameworkAppID" />
75-
</InputClaims>
76-
</TechnicalProfile>
77-
</TechnicalProfiles>
78-
</ClaimsProvider>
79-
</ClaimsProviders>
80-
```
81-
82-
### 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).
87-
88-
```XML
89-
<Item Key="client_id">8322dedc-cbf4-43bc-8bb6-141d16f0f489</Item>
90-
```
91-
92-
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
9653

97-
Add the sign-in claims provider for a local account to your user journey.
9854

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.
106-
107-
```XML
108-
<UserJourneys>
109-
<UserJourney Id="SignUpOrSignInWithKmsi">
110-
<OrchestrationSteps>
111-
<OrchestrationStep Order="1" Type="CombinedSignInAndSignUp" ContentDefinitionReferenceId="api.signuporsigninwithkmsi">
112-
<ClaimsProviderSelections>
113-
<ClaimsProviderSelection ValidationClaimsExchangeId="LocalAccountSigninEmailExchange" />
114-
</ClaimsProviderSelections>
115-
<ClaimsExchanges>
116-
<ClaimsExchange Id="LocalAccountSigninEmailExchange" TechnicalProfileReferenceId="SelfAsserted-LocalAccountSignin-Email" />
117-
</ClaimsExchanges>
118-
</OrchestrationStep>
119-
<OrchestrationStep Order="2" Type="ClaimsExchange">
120-
<Preconditions>
121-
<Precondition Type="ClaimsExist" ExecuteActionsIf="true">
122-
<Value>objectId</Value>
123-
<Action>SkipThisOrchestrationStep</Action>
124-
</Precondition>
125-
</Preconditions>
126-
<ClaimsExchanges>
127-
<ClaimsExchange Id="SignUpWithLogonEmailExchange" TechnicalProfileReferenceId="LocalAccountSignUpWithLogonEmail" />
128-
</ClaimsExchanges>
129-
</OrchestrationStep>
130-
<!-- This step reads any user attributes that we may not have received when in the token. -->
131-
<OrchestrationStep Order="3" Type="ClaimsExchange">
132-
<ClaimsExchanges>
133-
<ClaimsExchange Id="AADUserReadWithObjectId" TechnicalProfileReferenceId="AAD-UserReadUsingObjectId" />
134-
</ClaimsExchanges>
135-
</OrchestrationStep>
136-
<OrchestrationStep Order="4" Type="SendClaims" CpimIssuerTechnicalProfileReferenceId="JwtIssuer" />
137-
</OrchestrationSteps>
138-
<ClientDefinition ReferenceId="DefaultWeb" />
139-
</UserJourney>
140-
</UserJourneys>
141-
```
142-
143-
## Create a relying party file
55+
## Configure a relying party file
14456

14557
Update the relying party (RP) file that initiates the user journey that you created.
14658

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 `<DefaultUserJourney ReferenceId="User journey Id" />`, for example: `<DefaultUserJourney ReferenceId="SignUpOrSignIn" />`.
61+
1. Add the following node as a child of the `<UserJourneyBehaviors>` element.
15662

15763
```XML
158-
<RelyingParty>
159-
<DefaultUserJourney ReferenceId="SignUpOrSignInWithKmsi" />
160-
<UserJourneyBehaviors>
161-
<SingleSignOn Scope="Tenant" KeepAliveInDays="7" />
162-
<SessionExpiryType>Absolute</SessionExpiryType>
163-
<SessionExpiryInSeconds>1200</SessionExpiryInSeconds>
164-
</UserJourneyBehaviors>
165-
<TechnicalProfile Id="PolicyProfile">
166-
<DisplayName>PolicyProfile</DisplayName>
167-
<Protocol Name="OpenIdConnect" />
168-
<OutputClaims>
169-
<OutputClaim ClaimTypeReferenceId="displayName" />
170-
<OutputClaim ClaimTypeReferenceId="givenName" />
171-
<OutputClaim ClaimTypeReferenceId="surname" />
172-
<OutputClaim ClaimTypeReferenceId="email" />
173-
<OutputClaim ClaimTypeReferenceId="objectId" PartnerClaimType="sub"/>
174-
</OutputClaims>
175-
<SubjectNamingInfo ClaimType="sub" />
176-
</TechnicalProfile>
177-
</RelyingParty>
64+
<UserJourneyBehaviors>
65+
<SingleSignOn Scope="Tenant" KeepAliveInDays="30" />
66+
<SessionExpiryType>Absolute</SessionExpiryType>
67+
<SessionExpiryInSeconds>1200</SessionExpiryInSeconds>
68+
</UserJourneyBehaviors>
17869
```
17970

71+
- **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:
80+
81+
```XML
82+
<RelyingParty>
83+
<DefaultUserJourney ReferenceId="SignUpOrSignIn" />
84+
<UserJourneyBehaviors>
85+
<SingleSignOn Scope="Tenant" KeepAliveInDays="30" />
86+
<SessionExpiryType>Absolute</SessionExpiryType>
87+
<SessionExpiryInSeconds>1200</SessionExpiryInSeconds>
88+
</UserJourneyBehaviors>
89+
<TechnicalProfile Id="PolicyProfile">
90+
<DisplayName>PolicyProfile</DisplayName>
91+
<Protocol Name="OpenIdConnect" />
92+
<OutputClaims>
93+
<OutputClaim ClaimTypeReferenceId="displayName" />
94+
<OutputClaim ClaimTypeReferenceId="givenName" />
95+
<OutputClaim ClaimTypeReferenceId="surname" />
96+
<OutputClaim ClaimTypeReferenceId="email" />
97+
<OutputClaim ClaimTypeReferenceId="objectId" PartnerClaimType="sub"/>
98+
<OutputClaim ClaimTypeReferenceId="identityProvider" />
99+
<OutputClaim ClaimTypeReferenceId="tenantId" AlwaysUseDefaultValue="true" DefaultValue="{Policy:TenantObjectId}" />
100+
</OutputClaims>
101+
<SubjectNamingInfo ClaimType="sub" />
102+
</TechnicalProfile>
103+
</RelyingParty>
104+
```
105+
180106
4. Save your changes and then upload the file.
181107
5. To test the custom policy that you uploaded, in the Azure portal, go to the policy page, and then select **Run now**.
182108

0 commit comments

Comments
 (0)