2017-09-23 114 views
1

當從Web應用程序(ASP.Net MVC)調用時,Azure AD B2C是否支持在SignUp Policy中預先填充自定義屬性?Azure AD B2C在SignUp策略中預填充自定義屬性

我們可以創建一個自定義的SignUp屬性,但我們無法在文檔中找到如何傳遞值來填充自定義屬性的規範。如果這不支持開箱即用,是否有人找到解決方法?

下面是萬一有人的背景下一些細節也遇到過類似的情況,並發現了一個有用的解決方案:

我們探索解決與Azure的AD B2C以下情形的選項:註冊用戶邀請他人通過嚮應用程序的登錄頁面發送具有url的邀請電子郵件以及特殊的邀請代碼(guid)作爲查詢參數來註冊應用程序,因此它可以單擊該鏈接並將其重定向到註冊頁面。被邀請的人創建一個帳戶後,我們需要使用該代碼才能將新創建的用戶與發送邀請的用戶相關聯。

目前,這是在ASP.Net中使用默認身份提供程序(將用戶數據存儲在帶有AspNet ...表的數據庫中)中實現的。使用Azure AD B2C替換本地身份提供商後,我們在Azure AD B2C註冊頁面的往返過程中丟失了上下文。用戶點擊電子郵件上的鏈接並進入SIgnUp頁面,但邀請碼未預先填充。

+0

歡迎來到Stack Overflow。你已經嘗試過這麼做了什麼?請回顧[我如何問一個好問題](https://stackoverflow.com/help/how-to-ask)。堆棧溢出不是一種編碼服務。預計您會在發佈之前研究您的問題,並嘗試親自編寫代碼***。如果您遇到* specific *,請返回幷包含[Minimal,Complete和Verifiable示例](https://stackoverflow.com/help/mcve)以及您嘗試的內容摘要,以便我們提供幫助。 – FluffyKitten

+0

@FluffyKitten對此沒有具體說明?第一句話是一個非常具體的問題。並且我可能會添加一個很好的問題:)問候,Mike D. – spottedmahn

+1

@spottedmahn自從我發表評論以來,該問題已被編輯。但僅僅是單獨具體是不夠的 - 在我最初的評論中看到其餘的要求。 – FluffyKitten

回答

1

邀請流程的工作示例爲here

WingTipGamesWebApplication項目中,InvitationController控制器類有兩個操作方法,CreateRedeem

Create操作方法將已簽名的兌換鏈接發送給受邀用戶的電子郵件地址。此兌換鏈接包含此電子郵件地址。它也可以包含邀請碼。

Redeem操作方法處理兌換鏈接。它將電子郵件地址作爲verified_email聲明在由Wingtip Games應用程序的客戶端密鑰簽名的JWT中(請參閱中類中中的方法),從兌換鏈接到邀請政策。它也可以傳遞邀請碼。

邀請政策可以在here找到。

邀請政策聲明verified_email權利要求作爲輸入,根據權利要求:

<RelyingParty> 
    <DefaultUserJourney ReferenceId="Invitation" /> 
    <TechnicalProfile Id="Invitation"> 
    <InputTokenFormat>JWT</InputTokenFormat> 
     <CryptographicKeys> 
     <Key Id="client_secret" StorageReferenceId="WingTipGamesClientSecret" /> 
    </CryptographicKeys> 
    <InputClaims> 
     <InputClaim ClaimTypeReferenceId="extension_VerifiedEmail" /> 
    </InputClaims> 
    </TechnicalProfile> 
</RelyingParty> 

extension_verifiedEmail權利要求類型,它被聲明爲只讀字段(使得它不能被映射到verified_email輸入聲明:

<BuildingBlocks> 
    <ClaimsSchema> 
    <ClaimType Id="extension_VerifiedEmail"> 
     <DisplayName>Verified Email</DisplayName> 
     <DataType>string</DataType> 
     <DefaultPartnerClaimTypes> 
     <Protocol Name="OAuth2" PartnerClaimType="verified_email" /> 
     <Protocol Name="OpenIdConnect" PartnerClaimType="verified_email" /> 
     <Protocol Name="SAML2" PartnerClaimType="http://schemas.wingtipb2c.net/identity/claims/verifiedemail" /> 
     </DefaultPartnerClaimTypes> 
     <UserInputType>Readonly</UserInputType> 
    </ClaimType> 
    </ClaimsSchema> 
</BuildingBlocks> 

邀請用戶旅程可在here中找到。

邀請用戶旅程的第二編制步驟執行LocalAccount登記-VerifiedEmail技術簡介:

<UserJourney Id="Invitation"> 
    <OrchestrationSteps> 
    ... 
    <OrchestrationStep Order="2" Type="ClaimsExchange"> 
     <ClaimsExchanges> 
     ... 
     <ClaimsExchange Id="LocalAccountRegistrationExchange" TechnicalProfileReferenceId="LocalAccount-Registration-VerifiedEmail" /> 
     </ClaimsExchanges> 
    </OrchestrationStep> 
    </OrchestrationSteps> 
</UserJourney> 

LocalAccount登記-VerifiedEmail技術簡介與註冊的本地帳戶已驗證電子郵件地址:

<TechnicalProfile Id="LocalAccount-Registration-VerifiedEmail"> 
    <DisplayName>WingTip Account</DisplayName> 
    <Protocol Name="Proprietary" Handler="Web.TPEngine.Providers.SelfAssertedAttributeProvider, Web.TPEngine, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null" /> 
    <Metadata> 
    <Item Key="ContentDefinitionReferenceId">api.localaccount.registration</Item> 
    <Item Key="IpAddressClaimReferenceId">IpAddress</Item> 
    <Item Key="language.button_continue">Create</Item> 
    </Metadata> 
    <CryptographicKeys> 
    <Key Id="issuer_secret" StorageReferenceId="TokenSigningKeyContainer" /> 
    </CryptographicKeys> 
    <InputClaimsTransformations> 
    <InputClaimsTransformation ReferenceId="CreateEmailFromVerifiedEmail" /> 
    </InputClaimsTransformations> 
    <InputClaims> 
    <InputClaim ClaimTypeReferenceId="extension_VerifiedEmail" /> 
    </InputClaims> 
    <OutputClaims> 
    <OutputClaim ClaimTypeReferenceId="extension_VerifiedEmail" Required="true" /> 
    <OutputClaim ClaimTypeReferenceId="newPassword" Required="true" /> 
    <OutputClaim ClaimTypeReferenceId="reenterPassword" Required="true" /> 
    <OutputClaim ClaimTypeReferenceId="displayName" Required="true" /> 
    <OutputClaim ClaimTypeReferenceId="authenticationSource" DefaultValue="localAccountAuthentication" /> 
    <OutputClaim ClaimTypeReferenceId="executed-SelfAsserted-Input" DefaultValue="true" /> 
    <OutputClaim ClaimTypeReferenceId="newUser" /> 
    <OutputClaim ClaimTypeReferenceId="objectId" /> 
    <OutputClaim ClaimTypeReferenceId="sub" /> 
    <OutputClaim ClaimTypeReferenceId="userPrincipalName" /> 
    </OutputClaims> 
    <ValidationTechnicalProfiles> 
    <ValidationTechnicalProfile ReferenceId="AzureActiveDirectoryStore-WriteUserByEmail-ThrowIfExists" /> 
    </ValidationTechnicalProfiles> 
    <UseTechnicalProfileForSessionManagement ReferenceId="SSOSession-AzureActiveDirectory" /> 
</TechnicalProfile> 

要保存對本地帳戶的邀請碼,您必須:

  • 添加「extension_InvitationCode」要求權利要求的模式
  • 其添加爲輸入聲明到邀請政策
  • 其添加爲輸入聲明到LocalAccount登記-VerifiedEmail技術簡介
  • 添加它作爲一個持久要求的AzureActiveDirectoryStore-WriteUserByEmail-ThrowIfExist技術簡介
+0

感謝您的詳細解釋。爲了確認我們的理解 - 建議的解決方案是創建一個自定義策略,可以在驗證電子郵件的模型之後添加一個新屬性作爲聲明,並且此屬性將存儲在Azure AD B2C中,並在聲明之後作爲聲明返回給Web應用程序。來賓用戶註冊?實際上,遵循這個模型,可以添加許多自定義屬性,是否正確?要部署它,它只是上傳這些文件: .._ B2C_1A_base.xml .._ B2C_1A_base_extensions.xml .._ B2C_1A_invitation.xml 或其他步驟是必需的嗎? –

+1

對於上述所有問題,您都是正確的。向Web應用程序發出定製聲明將使Web應用程序能夠將邀請用戶與邀請用戶相鏈接。或者,您可以在用戶旅程中添加編排步驟,以調用REST式服務(例如Azure功能)來鏈接它們。 –

相關問題