Udostępnij za pośrednictwem

Weryfikacja koncepcji globalnej struktury tożsamości usługi Azure Active Directory B2C dla konfiguracji opartej na regionie

  • Artykuł

W poniższej sekcji opisano sposób tworzenia implementacji weryfikacji koncepcji na potrzeby orkiestracji opartej na regionie. Ukończone zasady niestandardowe usługi Azure Active Directory B2C (Azure AD B2C) można znaleźć tutaj.

Podejście oparte na regionach

Każda Azure AD regionalna dzierżawa usługi B2C będzie wymagać zasad niestandardowych usługi Azure AD B2C, które zawierają następujące możliwości:

Podróż do rejestracji:

  • Wyświetlanie ekranu w celu zebrania nazwy użytkownika, hasła i innych atrybutów
  • Nie zezwalaj na rejestrację, jeśli użytkownik już istnieje, wysyłając zapytanie do tabeli mapowania regionu użytkownika
  • Zapisywanie profilu użytkownika w dzierżawie lokalnej
  • Zapisywanie mapowania nazwy użytkownika do regionu użytkowników w tabeli mapowania
  • Wystawianie tokenu aplikacji

Podróż logowania:

  • Wyświetlanie ekranu nazwy użytkownika i hasła
  • Wyszukiwanie nazwy użytkownika i zwracanie jej regionu
  • Przeprowadzanie weryfikacji poświadczeń lokalnych lub weryfikacji poświadczeń między dzierżawami
  • Odczytywanie profilu użytkownika z dzierżawy lokalnej lub za pośrednictwem wywołania między dzierżawami
  • Wystawianie tokenu aplikacji

Podróż po resetowaniu hasła:

  • Wyświetlanie ekranu w celu zweryfikowania poczty e-mail użytkowników za pośrednictwem poczty e-mail OTP
  • Wyszukiwanie nazwy użytkownika i zwracanie jej regionu
  • Wyświetlanie ekranu w celu przechwycenia nowego hasła
  • Zapisywanie nowego hasła w dzierżawie lokalnej lub za pośrednictwem wywołania między dzierżawami
  • Wystawianie tokenu aplikacji

Na poniższym diagramie blokowym przedstawiono weryfikację koncepcji. Wskazówki pokazują, jak skonfigurować dzierżawy usługi Azure AD B2C. Warstwa interfejsu API zewnętrznego i tabela odnośników rozproszonych geograficznie nie jest uwzględniona w tym przewodniku.

Zrzut ekranu przedstawiający diagram bloków podejścia opartego na regionie

Wymagania wstępne

  1. Utwórz dzierżawę na region, który wymaga obsługi twojej firmy. Do weryfikacji koncepcji będą wymagane co najmniej dwie dzierżawy.

  2. Wdrażanie zasad niestandardowych w dzierżawach.

Przygotowywanie warstwy magazynu

Potrzebna będzie warstwa magazynu, która może przechowywać adres e-mail, identyfikator objectId i region użytkowników. Pozwoli to śledzić lokalizację, w której użytkownik się zarejestrował i wykonywać zapytania. Do utrwalania tych danych można użyć tabeli usługi Azure Storage .

Przygotowywanie warstwy interfejsu API

Istnieje wiele interfejsów API używanych w ramach weryfikacji koncepcji w celu zademonstrowania podejścia opartego na regionie.

Sprawdź, czy użytkownik już istnieje

Interfejs API jest używany podczas rejestracji, aby określić, czy użytkownik istnieje już w jakimkolwiek regionie.

Żądanie będzie wyglądać następująco:

POST /doesUserExistInLookupTable HTTP/1.1
Host: yourapi.com
Content-Type: application/json

{
  email: bob@contoso.com
}

  • Odpowiedź powinna być adresem HTTP 200, jeśli użytkownik nie istnieje.

  • Odpowiedź powinna być adresem HTTP 409, jeśli użytkownik istnieje.

Rejestrowanie mapowania regionów użytkowników

Interfejs API jest używany podczas rejestracji do rejestrowania regionu, w którym użytkownik się zarejestrował.

Żądanie będzie wyglądać następująco:

POST /userToRegionLookup HTTP/1.1
Host: yourapi.com
Authorization Bearer: <token>
Content-Type: application/json

{
  "email": "bob@contoso.com"
}

  • Odpowiedź powinna być adresem HTTP 200, jeśli użytkownik istnieje.

  • Odpowiedź powinna być adresem HTTP 409, jeśli użytkownik istnieje.

Zwracanie regionu, w którym znajduje się użytkownik

Interfejs API jest używany podczas logowania w celu określenia regionu, w którym użytkownik się zarejestrował. Wskazuje to, czy wymagane jest uwierzytelnianie między dzierżawami.

Żądanie będzie wyglądać następująco:

POST /userToRegionLookup HTTP/1.1
Host: yourapi.com
Authorization Bearer: <token>
Content-Type: application/json

{
  "email": "bob@contoso.com"
}

Odpowiedź powinna być adresem HTTP 200 z zarejestrowanym regionem użytkowników i identyfikatorem objectId.

{
  "objectId": "aaaaaaaa-0000-1111-2222-bbbbbbbbbbbb",
  "region": "APAC"  
}

Jeśli użytkownik nie istnieje lub napotka błąd, interfejs API powinien odpowiedzieć przy użyciu protokołu HTTP 409.

Zapisywanie hasła między dzierżawami

Interfejs API jest używany podczas przepływu resetowania hasła do zapisywania nowych haseł użytkowników w innym regionie, w którym resetują swoje hasło.

Żądanie będzie wyglądać następująco:

POST /writePasswordCrossTenant HTTP/1.1
Host: yourapi.com
Authorization Bearer: <token>
Content-Type: application/json

{
  "objectId": "aaaaaaaa-0000-1111-2222-bbbbbbbbbbbb",
  "password": "some!strong123STRING"
}

Odpowiedź powinna być adresem HTTP 200, jeśli proces zakończy się pomyślnie, lub HTTP 409, jeśli wystąpi błąd.

Konfiguracja Azure AD B2C oparta na regionie

W poniższych sekcjach przedstawiono przygotowanie dzierżawy usługi Azure AD B2C do śledzenia regionu, w którym użytkownik zarejestrował się i w razie potrzeby wykonał uwierzytelnianie między dzierżawami lub resetowanie haseł.

Konfiguracja zasad niestandardowych rejestracji

Podczas rejestracji musimy upewnić się, że użytkownik nie istnieje w żadnej innej dzierżawie i zapisać mapowanie użytkowników w regionie użytkownika do tabeli zewnętrznej.

Zmodyfikuj LocalAccountSignUpWithLogonEmail profil techniczny w pakiecie startowym usługi Azure AD B2C w następujący sposób:

<TechnicalProfile Id="LocalAccountSignUpWithLogonEmail">
...
  <ValidationTechnicalProfiles>            
    <ValidationTechnicalProfile ReferenceId="REST-getTokenforExternalApiCalls" />
    <ValidationTechnicalProfile ReferenceId="REST-doesUserExistInLookupTable" />        
    <ValidationTechnicalProfile ReferenceId="AAD-UserWriteUsingLogonEmail" />
    <ValidationTechnicalProfile ReferenceId="REST-writeUserToRegionMapping" />
  </ValidationTechnicalProfiles>
  <UseTechnicalProfileForSessionManagement ReferenceId="SM-AAD" />
</TechnicalProfile>

ValidationTechnicalProfiles wykona następującą logikę:

  1. Uzyskiwanie tokenu w celu wywoływania chronionych punktów końcowych interfejsu API przy użyciu profilu technicznego REST-getTokenforExternalApiCalls .

    • Postępuj zgodnie z dokumentacją tutaj, aby uzyskać i chronić interfejs API przy użyciu tokenu elementu nośnego Microsoft Entra.

  2. Sprawdź, czy użytkownik już istnieje w mapowaniu regionu użytkownika za pośrednictwem zabezpieczonego zewnętrznego punktu końcowego interfejsu API REST:

    • To wywołanie interfejsu API jest wykonywane przed wszystkimi rejestracjami, dlatego ważne jest, aby upewnić się, że ten interfejs API ma odpowiednie mechanizmy równoważenia obciążenia, odporności i trybu failover w celu zachowania wymagań dotyczących czasu pracy.

    • Przykład profilu technicznego do wykonywania zapytań dotyczących mapowania regionu użytkownika za pośrednictwem zewnętrznego interfejsu API REST jest następujący:

      <TechnicalProfile Id="REST-doesUserExistInLookupTable ">
<DisplayName>User to Region lookup</DisplayName>
<Protocol Name="Proprietary" Handler="Web.TPEngine.Providers.RestfulProvider, Web.TPEngine, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null" />
<Metadata>
  <Item Key="ServiceUrl">https://myApi.com/doesUserExistInLookupTable</Item>
  <Item Key="AuthenticationType">Bearer</Item>
  <Item Key="UseClaimAsBearerToken">ext_Api_bearerToken</Item>
  <Item Key="SendClaimsIn">Body</Item>
  <Item Key="AllowInsecureAuthInProduction">false</Item>
</Metadata>
<InputClaims>
  <InputClaim ClaimTypeReferenceId="ext_Api_bearerToken" />
  <InputClaim ClaimTypeReferenceId="signInName" PartnerClaimType="email" />
</InputClaims>
<UseTechnicalProfileForSessionManagement ReferenceId="SM-Noop" />
</TechnicalProfile>

    • Ten interfejs API powinien odpowiadać przy użyciu protokołu HTTP 409, jeśli użytkownik istnieje, z odpowiednim komunikatem o błędzie, który ma być wyświetlany na ekranie. W przeciwnym razie odpowiedz przy użyciu protokołu HTTP 200, jeśli użytkownik nie istnieje.

  3. Zapisywanie mapowania regionu użytkownika za pośrednictwem zabezpieczonego zewnętrznego punktu końcowego interfejsu API REST

    • To wywołanie interfejsu API jest wykonywane przed utworzeniem konta, dlatego ważne jest, aby upewnić się, że ten interfejs API ma odpowiednie mechanizmy równoważenia obciążenia, odporności i trybu failover w celu zachowania wymagań dotyczących czasu pracy.

    • Przykład profilu technicznego do zapisywania mapowania regionu użytkownika za pośrednictwem zewnętrznego interfejsu API REST jest następujący:

    <TechnicalProfile Id="REST-writeUserToRegionMapping">
<DisplayName>User to Region lookup</DisplayName>
<Protocol Name="Proprietary" Handler="Web.TPEngine.Providers.RestfulProvider, Web.TPEngine, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null" />
<Metadata>
  <Item Key="ServiceUrl">https://myApi.com/writeUserToRegionMapping</Item>
  <Item Key="AuthenticationType">Bearer</Item>
  <Item Key="UseClaimAsBearerToken">ext_Api_bearerToken</Item>
  <Item Key="SendClaimsIn">Body</Item>
  <Item Key="AllowInsecureAuthInProduction">false</Item>
</Metadata>
<InputClaims>
  <InputClaim ClaimTypeReferenceId="ext_Api_bearerToken" />
  <InputClaim ClaimTypeReferenceId="signInName" PartnerClaimType="email" />
  <InputClaim ClaimTypeReferenceId="region" DefaultValue="EMEA" />
  <InputClaim ClaimTypeReferenceId="objectId" />
</InputClaims>
<UseTechnicalProfileForSessionManagement ReferenceId="SM-Noop" />
</TechnicalProfile>
``` 

Konfiguracja zasad niestandardowych logowania

Podczas logowania musimy określić lokalizację profilu użytkowników i uwierzytelnić je w dzierżawie usługi Azure AD B2C, w której znajduje się ich profil.

Zmodyfikuj SelfAsserted-LocalAccountSignin-Email profil techniczny w pakiecie startowym usługi Azure AD B2C, aby wykonać wyszukiwanie w regionie użytkownika i przeprowadzić uwierzytelnianie między dzierżawami, gdy użytkownik pochodzi z innego regionu do dzierżawy, do której dotarł. Zaktualizuj element ValidationTechnicalProfiles jako:

<TechnicalProfile Id="SelfAsserted-LocalAccountSignin-Email">
...
  <ValidationTechnicalProfiles>
    <ValidationTechnicalProfile ReferenceId="REST-getTokenforExternalApiCalls" />
    <ValidationTechnicalProfile ReferenceId="REST-regionLookup" />
    <ValidationTechnicalProfile ReferenceId="login-NonInteractive">
      <Preconditions>
        <Precondition Type="ClaimEquals" ExecuteActionsIf="false">
          <Value>user_region</Value>
          <Value>EMEA</Value>
          <Action>SkipThisValidationTechnicalProfile</Action>
        </Precondition>
      </Preconditions>
     <ValidationTechnicalProfile ReferenceId="REST-login-NonInteractive-APAC">
      <Preconditions>
        <Precondition Type="ClaimEquals" ExecuteActionsIf="false">
          <Value>user_region</Value>
          <Value>APAC</Value>
          <Action>SkipThisValidationTechnicalProfile</Action>
        </Precondition>
      </Preconditions>
    </ValidationTechnicalProfile>
    <ValidationTechnicalProfile ReferenceId="REST-fetchUserProfile-APAC">
      <Preconditions>
        <Precondition Type="ClaimEquals" ExecuteActionsIf="false">
          <Value>user_region</Value>
          <Value>APAC</Value>
          <Action>SkipThisValidationTechnicalProfile</Action>
        </Precondition>
      </Preconditions>
    </ValidationTechnicalProfile>
  </ValidationTechnicalProfiles>
  <UseTechnicalProfileForSessionManagement ReferenceId="SM-AAD" />
</TechnicalProfile>

Funkcja ValidationTechnicalProfiles wykona następującą logikę, gdy użytkownik prześle swoje poświadczenia:

  1. Uzyskiwanie tokenu w celu wywoływania chronionych punktów końcowych interfejsu API przy użyciu profilu technicznego REST-getTokenforExternalApiCalls .

    • Postępuj zgodnie z dokumentacją tutaj, aby uzyskać i chronić interfejs API przy użyciu tokenu elementu nośnego Microsoft Entra.

  2. Wyszukiwanie mapowania regionu użytkownika za pośrednictwem zabezpieczonego zewnętrznego punktu końcowego interfejsu API REST

    • To wywołanie interfejsu API jest wykonywane przed wszystkimi rejestracjami, dlatego ważne jest, aby upewnić się, że ten interfejs API ma odpowiednie mechanizmy równoważenia obciążenia, odporności i trybu failover w celu zachowania wymagań dotyczących czasu pracy.

    • Przykład profilu technicznego do wykonywania zapytań dotyczących mapowania regionu użytkownika za pośrednictwem zewnętrznego interfejsu API REST jest następujący:

      <TechnicalProfile Id="REST-regionLookup">
  <DisplayName>User to Region lookup</DisplayName>
  <Protocol Name="Proprietary" Handler="Web.TPEngine.Providers.RestfulProvider, Web.TPEngine, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null" />
  <Metadata>
    <Item Key="ServiceUrl">https://myApi.com/userToRegionLookup</Item>
    <Item Key="AuthenticationType">Bearer</Item>
    <Item Key="UseClaimAsBearerToken">ext_Api_bearerToken</Item>
    <Item Key="SendClaimsIn">Body</Item>
    <Item Key="AllowInsecureAuthInProduction">false</Item>
  </Metadata>
  <InputClaims>
    <InputClaim ClaimTypeReferenceId="ext_Api_bearerToken" />
    <InputClaim ClaimTypeReferenceId="signInName" PartnerClaimType="email" />
  </InputClaims>
  <OutputClaims>
    <OutputClaim ClaimTypeReferenceId="user_region" PartnerClaimType="region" />
    <OutputClaim ClaimTypeReferenceId="objectId" PartnerClaimType="objectId" />
  </OutputClaims>
  <UseTechnicalProfileForSessionManagement ReferenceId="SM-Noop" />
</TechnicalProfile>

  3. Przeprowadź uwierzytelnianie konta lokalnego za pośrednictwem profilu technicznego login-NonInteractive dla użytkowników, którzy zarejestrowali się w tej dzierżawie. Jest to domyślny profil techniczny znaleziony w pakiecie startowym Azure AD B2C.

  4. Warunkowo należy przeprowadzić uwierzytelnianie między dzierżawami za pośrednictwem REST-login-NonInteractive-[region] profilów technicznych dla każdego odpowiedniego regionu.

    • Spowoduje to również uzyskanie tokenu MS interfejs Graph API z dzierżawy macierzystej użytkowników. Zarejestruj rejestrację aplikacji natywnej w każdej dzierżawie regionalnej z uprawnieniami do usługi MS interfejs Graph API w celu uzyskania delegowanego uprawnienia user.read.

    • Przykład profilu technicznego do wykonania mapowania regionu użytkownika za pośrednictwem zewnętrznego interfejsu API REST jest następujący:

      <TechnicalProfile Id="REST-login-NonInteractive-APAC">
  <DisplayName>non interactive authentication to APAC</DisplayName>
  <Protocol Name="Proprietary" Handler="Web.TPEngine.Providers.RestfulProvider, Web.TPEngine, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null" />
  <Metadata>
    <Item Key="ServiceUrl">https://login.microsoftonline.com/yourAPACb2ctenant.onmicrosoft.com/oauth2/v2.0/token</Item>
    <Item Key="AuthenticationType">None</Item>
    <Item Key="SendClaimsIn">Form</Item>
    <Item Key="AllowInsecureAuthInProduction">true</Item>
  </Metadata>
  <InputClaims>
    <InputClaim ClaimTypeReferenceId="apac_client_id" PartnerClaimType="client_id" DefaultValue="00001111-aaaa-2222-bbbb-3333cccc4444" />
    <InputClaim ClaimTypeReferenceId="ropc_grant_type" PartnerClaimType="grant_type" DefaultValue="password" />
    <InputClaim ClaimTypeReferenceId="signInName" PartnerClaimType="username" />
    <InputClaim ClaimTypeReferenceId="password" />
    <InputClaim ClaimTypeReferenceId="scope" DefaultValue="https://graph.microsoft.com/.default" AlwaysUseDefaultValue="true" />
    <InputClaim ClaimTypeReferenceId="nca" PartnerClaimType="nca" DefaultValue="1" />
  </InputClaims>
  <OutputClaims>
    <OutputClaim ClaimTypeReferenceId="ext_Api_bearerToken" PartnerClaimType="access_token" />
  </OutputClaims>
  <UseTechnicalProfileForSessionManagement ReferenceId="SM-Noop" />
</TechnicalProfile>

    • Zastąp <yourb2ctenant> element w ServiceUrl dzierżawie, która ma być docelowa na potrzeby uwierzytelniania.

    • Użyj rejestracji ApplicationId aplikacji, aby wypełnić DefaultValue element dla oświadczenia wejściowego apac_client_id .

  5. Warunkowo pobierz profil użytkownika przy użyciu wywołania interfejsu API REST między dzierżawami za pośrednictwem REST-fetchUserProfile-[region] profilów technicznych dla każdego regionu.

    • Przykładowy profil techniczny odczytu profilu użytkownika za pośrednictwem ms interfejs Graph API jest następujący:

      <TechnicalProfile Id="REST-fetchUserProfile-APAC">
  <DisplayName>fetch user profile cross tenant</DisplayName>
  <Protocol Name="Proprietary" Handler="Web.TPEngine.Providers.RestfulProvider, Web.TPEngine, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null" />
  <Metadata>
    <Item Key="ServiceUrl">https://graph.microsoft.com/beta/me</Item>
    <Item Key="AuthenticationType">Bearer</Item>
    <Item Key="UseClaimAsBearerToken">graph_bearerToken</Item>
    <Item Key="SendClaimsIn">Body</Item>
  </Metadata>
  <InputClaims>
    <InputClaim ClaimTypeReferenceId="graph_bearerToken" />
  </InputClaims>
  <OutputClaims>
    <OutputClaim ClaimTypeReferenceId="objectId" PartnerClaimType="id" />
    <OutputClaim ClaimTypeReferenceId="givenName" />
    <OutputClaim ClaimTypeReferenceId="surName" />
    <OutputClaim ClaimTypeReferenceId="displayName" />
    <OutputClaim ClaimTypeReferenceId="userPrincipalName" PartnerClaimType="upn" />
    <OutputClaim ClaimTypeReferenceId="authenticationSource" DefaultValue="localAccountAuthentication" />
  </OutputClaims>
  <UseTechnicalProfileForSessionManagement ReferenceId="SM-Noop" />
</TechnicalProfile>

Konfiguracja zasad niestandardowych resetowania haseł

Podczas resetowania hasła musimy określić lokalizację profilu użytkowników i zaktualizować hasło względem dzierżawy usługi Azure AD B2C, w której znajduje się profil użytkownika.

Zmodyfikuj LocalAccountSignUpWithLogonEmail profil techniczny w pakiecie startowym usługi Azure AD B2C, aby wyszukać użytkownika w regionie użytkownika i zaktualizować hasło w odpowiedniej dzierżawie. Zaktualizuj element ValidationTechnicalProfiles jako:

<TechnicalProfile Id="LocalAccountDiscoveryUsingEmailAddress">
  <OutputClaims>
  ...
  <OutputClaim ClaimTypeReferenceId="ext_Api_bearerToken" DefaultValue="EMEA"/>
  </OutputClaims>
  <ValidationTechnicalProfiles>
    <ValidationTechnicalProfile ReferenceId="REST-getTokenforExternalApiCalls">
      <Preconditions>
        <Precondition Type="ClaimEquals" ExecuteActionsIf="true">
          <Value>user_region</Value>
          <Value>EMEA</Value>
          <Action>SkipThisValidationTechnicalProfile</Action>
        </Precondition>
      </Preconditions>
    </ValidationTechnicalProfile>
    <ValidationTechnicalProfile ReferenceId="REST-regionLookup" />
    <ValidationTechnicalProfile ReferenceId="AAD-UserReadUsingEmailAddress" />
  </ValidationTechnicalProfiles>
</TechnicalProfile>

ValidationTechnicalProfiles wykona następującą logikę, gdy użytkownik prześle zweryfikowaną wiadomość e-mail w celu zaktualizowania hasła:

  1. Uzyskiwanie tokenu w celu wywołania chronionych punktów końcowych interfejsu API

  2. Wyszukiwanie mapowania regionu użytkownika za pośrednictwem zabezpieczonego zewnętrznego punktu końcowego interfejsu API REST

    • To wywołanie interfejsu API jest wykonywane przed wszystkimi próbami resetowania hasła, ważne jest, aby upewnić się, że ten interfejs API ma odpowiednie równoważenie obciążenia, odporność i mechanizmy trybu failover w celu zachowania wymagań dotyczących czasu pracy.

Zmodyfikuj profil techniczny, LocalAccountWritePasswordUsingObjectId aby zapisać nowe hasło do dzierżawy lokalnej lub warunkowo w dzierżawie obejmującej wiele regionów.

<TechnicalProfile Id="LocalAccountWritePasswordUsingObjectId">
  ...
  <ValidationTechnicalProfiles>
    <ValidationTechnicalProfile ReferenceId="AAD-UserWritePasswordUsingObjectId">
        <Preconditions>
          <Precondition Type="ClaimEquals" ExecuteActionsIf="false">
            <Value>user_region</Value>
            <Value>EMEA</Value>
            <Action>SkipThisValidationTechnicalProfile</Action>
          </Precondition>
        </Preconditions>
      </ValidationTechnicalProfile>
    <ValidationTechnicalProfile ReferenceId="REST-UserWritePasswordUsingObjectId-APAC">
        <Preconditions>
          <Precondition Type="ClaimEquals" ExecuteActionsIf="false">
            <Value>user_region</Value>
            <Value>APAC</Value>
            <Action>SkipThisValidationTechnicalProfile</Action>
          </Precondition>
        </Preconditions>
      </ValidationTechnicalProfile>
  </ValidationTechnicalProfiles>
</TechnicalProfile>

Plik ValidationTechnicalProfiles wykona następującą logikę, gdy użytkownik prześle nowe hasło:

  1. Napisz nowe hasło użytkowników do katalogu, jeśli użytkownik istniał w dzierżawie EMEA (tej dzierżawie).

  2. Warunkowo napisz nowe hasło do profilu użytkownika w regionie, w którym mieszka profil użytkownika, przy użyciu wywołania interfejsu API REST.

    <TechnicalProfile Id="REST-UserWritePasswordUsingObjectId-APAC">
  <DisplayName>Write password to APAC tenant</DisplayName>
  <Protocol Name="Proprietary" Handler="Web.TPEngine.Providers.RestfulProvider, Web.TPEngine, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null" />
  <Metadata>
    <Item Key="ServiceUrl">https://myApi.com/writePasswordCrossTenant</Item>
    <Item Key="AuthenticationType">Bearer</Item>
    <Item Key="UseClaimAsBearerToken">ext_Api_bearerToken</Item>
    <Item Key="SendClaimsIn">Body</Item>
    <Item Key="DebugMode">true</Item>
  </Metadata>
  <InputClaims>
    <InputClaim ClaimTypeReferenceId="ext_Api_bearerToken" />
    <InputClaim ClaimTypeReferenceId="objectId" />
    <InputClaim ClaimTypeReferenceId="newPassword" />
  </InputClaims>
  <UseTechnicalProfileForSessionManagement ReferenceId="SM-Noop" />
</TechnicalProfile>

Następne kroki