英文:
Azure AD B2C Custom Policy: obtaining newUser attribute
问题
以下是您要翻译的内容：
第一个解决方案：
这是我的第一个解决方案，这个技术配置文件的目的是注册部分，我尝试将newUser设置为此处的Output声明。但是我意识到它不起作用，因为它位于SM-Noop中。
第二个解决方案：
现在，对于第二个解决方案，我尝试在RelyingParty中将newUser声明为Output声明。
我在哪里出错了？我在Google和StackOverflow上看到的大多数解决方案与"用户流"有关。我可能错过了什么，但我不知道是什么。
感谢您的帮助！如果您需要更多信息，请告诉我。
英文:
I have some questions regarding AAD B2C Custom Policies. So here is my problem, I want to obtain the newUser attribute but I am not really sure what I'm doing wrong.
This was my first solution, the purpose for this technical profile is the signup part, I've tried putting the newUser as an Output claim here. But I realize it does not work due to it being in SM-Noop.
<TechnicalProfile Id="NewUserAccountUpdatePrimaryDetails">
<DisplayName>Profile creation using read only email</DisplayName>
<Protocol Name="Proprietary" Handler="Web.TPEngine.Providers.SelfAssertedAttributeProvider, Web.TPEngine, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null" />
<Metadata>
<Item Key="IpAddressClaimReferenceId">IpAddress</Item>
<Item Key="ContentDefinitionReferenceId">api.localaccountsignup</Item>
<Item Key="language.button_continue">Next</Item>
<!-- Sample: Remove sign-up email verification -->
<Item Key="EnforceEmailVerification">False</Item>
</Metadata>
<InputClaimsTransformations>
<InputClaimsTransformation ReferenceId="CreateReadonlyEmailClaim" />
</InputClaimsTransformations>
<InputClaims>
<!--Sample: Set input the ReadOnlyEmail claim type to prefilled the email address-->
<InputClaim ClaimTypeReferenceId="readOnlyEmail" />
<InputClaim ClaimTypeReferenceId="country" />
<!-- Optional claims, to be collected from the user -->
<InputClaim ClaimTypeReferenceId="displayName" />
<InputClaim ClaimTypeReferenceId="givenName" />
<InputClaim ClaimTypeReferenceId="surName" />
<InputClaim ClaimTypeReferenceId="streetAddress" />
<InputClaim ClaimTypeReferenceId="city" />
<InputClaim ClaimTypeReferenceId="state" />
<InputClaim ClaimTypeReferenceId="postalCode" />
</InputClaims>
<OutputClaims>
<OutputClaim ClaimTypeReferenceId="readOnlyEmail" Required="true" />
<OutputClaim ClaimTypeReferenceId="newPassword" Required="true" />
<OutputClaim ClaimTypeReferenceId="reenterPassword" Required="true" />
<OutputClaim ClaimTypeReferenceId="executed-SelfAsserted-Input" DefaultValue="true" />
<OutputClaim ClaimTypeReferenceId="authenticationSource" />
<OutputClaim ClaimTypeReferenceId="country" Required="true" />
<OutputClaim ClaimTypeReferenceId="displayName" Required="true"/>
<OutputClaim ClaimTypeReferenceId="givenName" Required="true"/>
<OutputClaim ClaimTypeReferenceId="surName" Required="true"/>
<OutputClaim ClaimTypeReferenceId="newUser" />
<!-- Optional claims, to be collected from the user -->
<OutputClaim ClaimTypeReferenceId="streetAddress" />
<OutputClaim ClaimTypeReferenceId="city" />
<OutputClaim ClaimTypeReferenceId="state" />
<OutputClaim ClaimTypeReferenceId="postalCode" />
</OutputClaims>
<ValidationTechnicalProfiles>
<ValidationTechnicalProfile ReferenceId="AAD-UserWriteUsingLogonEmail-ProfileUpdate" />
</ValidationTechnicalProfiles>
<UseTechnicalProfileForSessionManagement ReferenceId="SM-Noop" />
</TechnicalProfile>
Now for the second solution I've tried is to declare the newUser as Output claim in RelyingParty.
<RelyingParty>
<DefaultUserJourney ReferenceId="CheckPassReset" />
<UserJourneyBehaviors>
<SingleSignOn Scope="Tenant" />
<JourneyInsights TelemetryEngine="ApplicationInsights" InstrumentationKey="4b408c9c-6ef1-43db-82e7-6368e1fc1536"
DeveloperMode="true" ClientEnabled="false" ServerEnabled="true" TelemetryVersion="1.0.0" />
<ScriptExecution>Allow</ScriptExecution>
</UserJourneyBehaviors>
<TechnicalProfile Id="PolicyProfile">
<DisplayName>PolicyProfile</DisplayName>
<Protocol Name="OpenIdConnect" />
<OutputClaims>
<OutputClaim ClaimTypeReferenceId="email" />
<OutputClaim ClaimTypeReferenceId="objectId" PartnerClaimType="sub"/>
<OutputClaim ClaimTypeReferenceId="displayName" />
<OutputClaim ClaimTypeReferenceId="givenName" />
<OutputClaim ClaimTypeReferenceId="surname" />
<OutputClaim ClaimTypeReferenceId="newUser" />
<OutputClaim ClaimTypeReferenceId="tenantId" AlwaysUseDefaultValue="true" DefaultValue="{Policy:TenantObjectId}" />
</OutputClaims>
<SubjectNamingInfo ClaimType="sub" />
</TechnicalProfile>
</RelyingParty>
Where did I go wrong with this? Most of the solutions I've seen in Google and StackOverflow is related to User Flow. I've probably missed something but I don't know what.
Thank you for the help! If you need any more information, please tell me.
答案1
得分: 1
在自定义策略入门套件中，newUser 声明由创建用户的技术配置文件生成（AAD-UserWriteUsingLogonEmail）：
<OutputClaim ClaimTypeReferenceId="newUser" PartnerClaimType="newClaimsPrincipalCreated" />
它执行针对 Graph API 的写操作，如果这创建了一个新用户，newClaimsPrincipalCreated 会返回 true。
然后，上述输出声明将其映射到 newUser 声明，然后您在后续步骤中使用它。
在您的示例中，AAD-UserWriteUsingLogonEmail-ProfileUpdate 听起来像是在更新用户个人资料时执行的写操作。
如果在这种情况下用户已存在，newUser 声明将始终返回 false。
如果情况不是这样，您需要将 newUser 声明添加为输出声明。
看起来这是一个密码重置流程，在这种情况下，用户将始终已经存在。
因此，newUser 将始终为 false。
英文:
In the custom policy starter pack, the newUser claim is produced by the technical profile that creates the user (AAD-UserWriteUsingLogonEmail):
<OutputClaim ClaimTypeReferenceId="newUser" PartnerClaimType="newClaimsPrincipalCreated" />
It is running a write operation against the Graph API, and if this creates a new user, newClaimsPrincipalCreated returns true.
The above output claim then maps this to the newUser claim, that you then use in the following steps.
In your example, AAD-UserWriteUsingLogonEmail-ProfileUpdate sounds like a write done while updating the user's profile.
If in this case the user already exists, the newUser claim would always return false.
If that is not the case, you would need to add the newUser claim as an output claim there.
It does seem like this is a password reset flow, in which the user will always exist already.
So newUser would always be false.
通过集体智慧和协作来改善编程学习和解决问题的方式。致力于成为全球开发者共同参与的知识库，让每个人都能够通过互相帮助和分享经验来进步。
评论