RelyingParty

Das RelyingParty-Element legt die User Journey fest, die für die aktuelle Anforderung an Azure Active Directory B2C (Azure AD B2C) erzwungen werden soll. Es legt außerdem die Liste von Ansprüchen fest, die die Anwendung der vertrauenden Seite als Teil des ausgestellten Tokens benötigt. Eine Anwendung der vertrauenden Seite, z.B. eine Web-, mobile oder Desktopanwendung, ruft die Richtliniendatei der vertrauenden Seite auf. Die Richtliniendatei der vertrauenden Seite führt eine bestimmte Aufgabe aus, z.B. eine Anmeldung, das Zurücksetzen eines Kennworts oder eine Profilbearbeitung. Mehrere Anwendungen können die gleiche Anwendung der vertrauenden Seite verwenden, und eine einzelne Anwendung kann mehrere Richtlinien verwenden. Alle Anwendungen der vertrauenden Seite erhalten das gleiche Token mit Ansprüchen, und der Benutzer durchläuft die gleiche User Journey.

Im folgenden Beispiel wird ein RelyingParty-Element in der Richtliniendatei B2C_1A_signup_signin gezeigt:

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<TrustFrameworkPolicy
  xmlns:xsi="https://www.w3.org/2001/XMLSchema-instance"
  xmlns:xsd="https://www.w3.org/2001/XMLSchema"
  xmlns="http://schemas.microsoft.com/online/cpim/schemas/2013/06"
  PolicySchemaVersion="0.3.0.0"
  TenantId="your-tenant.onmicrosoft.com"
  PolicyId="B2C_1A_signup_signin"
  PublicPolicyUri="http://your-tenant.onmicrosoft.com/B2C_1A_signup_signin">

  <BasePolicy>
    <TenantId>your-tenant.onmicrosoft.com</TenantId>
    <PolicyId>B2C_1A_TrustFrameworkExtensions</PolicyId>
  </BasePolicy>

  <RelyingParty>
    <DefaultUserJourney ReferenceId="SignUpOrSignIn" />
    <UserJourneyBehaviors>
      <SingleSignOn Scope="Tenant" KeepAliveInDays="7"/>
      <SessionExpiryType>Rolling</SessionExpiryType>
      <SessionExpiryInSeconds>900</SessionExpiryInSeconds>
      <JourneyInsights TelemetryEngine="ApplicationInsights" InstrumentationKey="your-application-insights-key" DeveloperMode="true" ClientEnabled="false" ServerEnabled="true" TelemetryVersion="1.0.0" />
      <ContentDefinitionParameters>
        <Parameter Name="campaignId">{OAUTH-KV:campaignId}</Parameter>
      </ContentDefinitionParameters>
    </UserJourneyBehaviors>
    <TechnicalProfile Id="PolicyProfile">
      <DisplayName>PolicyProfile</DisplayName>
      <Description>The policy profile</Description>
      <Protocol Name="OpenIdConnect" />
      <Metadata>collection of key/value pairs of data</Metadata>
      <OutputClaims>
        <OutputClaim ClaimTypeReferenceId="displayName" />
        <OutputClaim ClaimTypeReferenceId="givenName" />
        <OutputClaim ClaimTypeReferenceId="surname" />
        <OutputClaim ClaimTypeReferenceId="email" />
        <OutputClaim ClaimTypeReferenceId="objectId" PartnerClaimType="sub"/>
        <OutputClaim ClaimTypeReferenceId="identityProvider" />
        <OutputClaim ClaimTypeReferenceId="loyaltyNumber" />
      </OutputClaims>
      <SubjectNamingInfo ClaimType="sub" />
    </TechnicalProfile>
  </RelyingParty>
  ...

Das optionale RelyingParty-Element enthält die folgenden Elemente:

Sie müssen die untergeordneten RelyingParty-Elemente in der Reihenfolge erstellen, die in der vorherigen Tabelle angegeben ist.

Endpunkte

Das Element Endpoints enthält das folgende Element:

Das Element Endpoint enthält die folgenden Attribute:

Das folgende Beispiel zeigt eine vertrauende Seite mit UserInfo-Endpunkt:

<RelyingParty>
  <DefaultUserJourney ReferenceId="SignUpOrSignIn" />
  <Endpoints>
    <Endpoint Id="UserInfo" UserJourneyReferenceId="UserInfoJourney" />
  </Endpoints>
  ...

DefaultUserJourney

Durch das Element DefaultUserJourney wird ein Verweis auf den Bezeichner der User Journey angegeben, die in der Basis- oder Erweiterungsrichtlinie definiert ist. In den folgenden Beispielen wird die im RelyingParty-Element angegebene User Journey für die Registrierung oder Anmeldung dargestellt:

B2C_1A_signup_signin-Richtlinie:

<RelyingParty>
  <DefaultUserJourney ReferenceId="SignUpOrSignIn">
  ...

B2C_1A_TrustFrameWorkBase oder B2C_1A_TrustFrameworkExtensionPolicy:

<UserJourneys>
  <UserJourney Id="SignUpOrSignIn">
  ...

Das DefaultUserJourney-Element enthält das folgende Attribut:

UserJourneyBehaviors

Das UserJourneyBehaviors-Element enthält die folgenden Elemente:

Wenn Sie die oben aufgeführten Elemente verwenden, müssen diese Ihrem UserJourneyBehaviors-Element in der in der Tabelle angegebenen Reihenfolge hinzugefügt werden. Beispielsweise muss das JourneyInsights-Element vor (über) dem ScriptExecution-Element hinzugefügt werden.

SingleSignOn

Das SingleSignOn-Element enthält die folgenden Attribute:

JourneyInsights

Das JourneyInsights-Element enthält die folgenden Attribute:

Weitere Informationen finden Sie unter Erfassen von Protokollen.

ContentDefinitionParameters

Mithilfe benutzerdefinierter Richtlinien in Azure AD B2C können Sie einen Parameter in einer Abfragezeichenfolge senden. Durch Übergeben des Parameters an Ihren HTML-Endpunkt können Sie den Seiteninhalt dynamisch ändern. Sie können z.B. das Hintergrundbild auf der Azure AD B2C-Registrierungs- oder Anmeldeseite auf der Basis eines Parameters ändern, den Sie von der Web- oder Mobilanwendung übergeben. Azure AD B2C übergibt die Abfragezeichenfolgenparameter an Ihre dynamische HTML-Datei, z.B. eine ASPX-Datei.

Im folgenden Beispiel wird ein Parameter namens campaignId mit dem Wert hawaii in der Abfragezeichenfolge übergeben:

https://login.microsoft.com/contoso.onmicrosoft.com/oauth2/v2.0/authorize?pB2C_1A_signup_signin&client_id=00001111-aaaa-2222-bbbb-3333cccc4444&nonce=defaultNonce&redirect_uri=http%3A%2F%2Fjwt.io%2F&scope=openid&response_type=id_token&prompt=login&campaignId=hawaii

Das ContentDefinitionParameters-Element enthält das folgende Element:

Das ContentDefinitionParameter-Element enthält das folgende Attribut:

Weitere Informationen finden Sie unter Konfigurieren der Benutzeroberfläche mit dynamischen Inhalten mithilfe von benutzerdefinierten Richtlinien.

JourneyFraming

Das JourneyFraming-Element enthält die folgenden Attribute:

TechnicalProfile

Das TechnicalProfile-Element enthält die folgenden Attribute:

TechnicalProfile enthält die folgenden Elemente:

Das Protocol-Element enthält die folgenden Attribute:

Metadaten

Wenn SAML das Protokoll ist, enthält ein Metadatenelement die folgenden Elemente: Weitere Informationen finden Sie in den Optionen zum Registrieren einer SAML-Anwendung in Azure AD B2C.

InputClaims

Das InputClaims-Element enthält das folgende Element:

Das InputClaim-Element enthält die folgenden Attribute:

OutputClaims

Das OutputClaims-Element enthält das folgende Element:

Das OutputClaim-Element enthält die folgenden Attribute:

SubjectNamingInfo

Mit dem SubjectNamingInfo-Element steuern Sie den Wert des Tokenbetreffs:

• JWT-Token: Der sub-Anspruch. Dies ist ein Prinzipal, für den das Token Informationen zusichert, z.B. der Benutzer einer Anwendung. Dieser Wert ist unveränderlich und kann nicht erneut zugewiesen oder wiederverwendet werden. Er kann für die Durchführung von sicheren Autorisierungsüberprüfungen verwendet werden, z.B. wenn das Token verwendet wird, um auf eine Ressource zuzugreifen. Der Anspruch „Antragsteller“ wird standardmäßig mit der Objekt-ID des Benutzers im Verzeichnis aufgefüllt. Weitere Informationen finden Sie unter Token, Sitzung und einmaliges Anmelden – Konfiguration.
• SAML-Token: Das Element <Subject><NameID>, das das Antragstellerelement identifiziert. Das NameID-Format kann geändert werden.

Das SubjectNamingInfo-Element enthält das folgende Attribut:

Im folgenden Beispiel wird gezeigt, wie eine vertrauende OpenID Connect-Seite definiert wird. Die Informationen zum Namen des Antragstellers werden als objectId konfiguriert:

<RelyingParty>
  <DefaultUserJourney ReferenceId="SignUpOrSignIn" />
  <TechnicalProfile Id="PolicyProfile">
    <DisplayName>PolicyProfile</DisplayName>
    <Protocol Name="OpenIdConnect" />
    <OutputClaims>
      <OutputClaim ClaimTypeReferenceId="displayName" />
      <OutputClaim ClaimTypeReferenceId="givenName" />
      <OutputClaim ClaimTypeReferenceId="surname" />
      <OutputClaim ClaimTypeReferenceId="email" />
      <OutputClaim ClaimTypeReferenceId="objectId" PartnerClaimType="sub"/>
      <OutputClaim ClaimTypeReferenceId="identityProvider" />
    </OutputClaims>
    <SubjectNamingInfo ClaimType="sub" />
  </TechnicalProfile>
</RelyingParty>

Das JWT-Token enthält den sub-Anspruch mit der Objekt-ID des Benutzers:

{
  ...
  "sub": "aaaaaaaa-0000-1111-2222-bbbbbbbbbbbb",
  ...
}

Im folgenden Beispiel wird gezeigt, wie eine vertrauende SAML-Seite definiert wird. Die Informationen zum Namen des Antragstellers werden als objectId konfiguriert, und die „NameID“ format wurde angegeben:

<RelyingParty>
  <DefaultUserJourney ReferenceId="SignUpOrSignIn" />
  <TechnicalProfile Id="PolicyProfile">
    <DisplayName>PolicyProfile</DisplayName>
    <Protocol Name="SAML2" />
    <OutputClaims>
      <OutputClaim ClaimTypeReferenceId="displayName" />
      <OutputClaim ClaimTypeReferenceId="givenName" />
      <OutputClaim ClaimTypeReferenceId="surname" />
      <OutputClaim ClaimTypeReferenceId="email" />
      <OutputClaim ClaimTypeReferenceId="objectId" PartnerClaimType="sub"/>
      <OutputClaim ClaimTypeReferenceId="identityProvider" />
    </OutputClaims>
    <SubjectNamingInfo ClaimType="sub" Format="urn:oasis:names:tc:SAML:2.0:nameid-format:transient"/>
  </TechnicalProfile>
</RelyingParty>