2017-12-01 4 views
1

Ich habe 2 Ansprüche, die ich im Verzeichnis für meine Anwendung speichern möchte. Diese stehen dem Benutzer nicht zum Bearbeiten zur Verfügung, stehen jedoch der Anwendung zum Lesen aus dem Token zur Verfügung.Lesen von Erweiterungen Ansprüche in Azure AD B2C

Die BuiltIn-Richtlinien sind in der Lage, die Ansprüche abzurufen, aber ich hatte keinen Erfolg beim Abrufen dieser Ansprüche mit benutzerdefinierten Richtlinien.

Lesen von Next Steps des Artikels "Erstellen und Verwenden von benutzerdefinierten Attributen in einer benutzerdefinierten Profil bearbeiten Richtlinie" die Ansprüche müssen zum RP hinzugefügt werden und TechnicalProfile aus dem Verzeichnis zu lesen. Ich den RP entsprechend aktualisiert und auch die TP, dass das von Directory gelesen wie

<TechnicalProfile Id="AAD-UserReadUsingAlternativeSecurityId"> 
<TechnicalProfile Id="AAD-UserReadUsingObjectId"> 
<TechnicalProfile Id="SelfAsserted-LocalAccountSignin-Email"> 
<TechnicalProfile Id="AAD-UserReadUsingEmailAddress"> 

kann nicht herausfinden, was die 2 Verlängerungsansprüche retreive könnte fehlen.

Antwort

2

Vorausgesetzt, dass Sie die benutzerdefinierten Ansprüche in den Benutzern Reisen lesen und über die Azure AD Graph API zu schreiben, dann müssen Sie:

1: Fügen Sie die benutzerdefinierten Ansprüche als <ClaimType /> s an die Basispolitik.

<ClaimType Id="extension_UserAttribute1"> 
    <DisplayName>User Attribute 1</DisplayName> 
    <DataType>string</DataType> 
</ClaimType> 
<ClaimType Id="extension_UserAttribute2"> 
    <DisplayName>User Attribute 2</DisplayName> 
    <DataType>string</DataType> 
</ClaimType> 

2: Fügen Sie die Anwendung und Objekt-Identifikatoren für the extensions app zum „AAD-Common“ technischen Profil, die erforderlich ist, um die kundenspezifische Forderungen aus dem Azure AD B2C-Verzeichnis zu lesen.

<TechnicalProfile Id="AAD-Common"> 
    <DisplayName>Azure Active Directory</DisplayName> 
    <Protocol Name="Proprietary" Handler="Web.TPEngine.Providers.AzureActiveDirectoryProvider, Web.TPEngine, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null" /> 
    <Metadata> 
    <Item Key="ApplicationObjectId">Insert the object identifier for the b2c-extensions-app application here</Item> 
    <Item Key="ClientId">Insert the application identifier for the b2c-extensions-app application here</Item> 
    </Metadata> 
    <CryptographicKeys> 
    <Key Id="issuer_secret" StorageReferenceId="TokenSigningKeyContainer" /> 
    </CryptographicKeys> 
    ... 
</TechnicalProfile> 

Hinweis: Wenn Sie wollen, um die benutzerdefinierten Ansprüche in beiden integrierten Richtlinien und benutzerdefinierten Richtlinien lesen, dann müssen Sie die Anwendung und Objekt-IDs für den Einbau-b2c-extensions-App verwenden Anwendung statt einer benutzerdefinierten Erweiterungen App wie von der Azure Active Directory B2C: Creating and using custom attributes in a custom profile edit policy Tutorial vorgeschlagen.

3: die benutzerdefinierten Ansprüche als <OutputClaim /> s auf die folgenden technischen Profilen hinzufügen:

"AAD-UserReadUsingObjectId" für lokales Konto Anmelde- und Profilbearbeitung

"AAD-UserReadUsingAlternativeSecurityId" für ein soziales Konto Anmelde- und Profilbearbeitung

"LocalAccountDiscoveryUsingEmailAddress" und "AAD-UserReadUsingEmailAddress" für ein lokales Konto Passwort zurücksetzen

<OutputClaims> 
    ... 
    <OutputClaim ClaimTypeReferenceId="extension_UserAttribute1" /> 
    <OutputClaim ClaimTypeReferenceId="extension_UserAttribute2" /> 
</OutputClaims> 

4: Geben Sie die benutzerdefinierten Ansprüche als <OutputClaim /> s in Richtlinien für vertrauende Parteien ein.

0

Dank Chris ... ich meine TrustExtensions Datei überprüft und festgestellt, dass mein ObjId eine Diskrepanz zu b2c-Erweiterung App war ... Sobald ich es korrigierte es geklappt .... DANKE ...

+0

Excellent !, Jay, wenn du glaubst, dass die obige Antwort anderen helfen kann, kannst du das bitte so markieren? –