Как я могу сопоставить свойство из входа в Azure AD с удостоверением B2C?

Следуя этому примеру, https://docs.microsoft.com/en-us/azure/active-directory-b2c/active-directory-b2c-setup-aad-custom нам удалось интегрировать каталог Azure AD ('AD') с каталогом Azure AD B2C («B2C»), чтобы мы могли зарегистрироваться в общедоступном приложении в социальных сетях и с самоутверждением, в которое наши рабочие пользователи также могут входить со своими обычными рабочими идентификаторами. Это хорошо работает и решает за нас сложный сценарий.

В приложении, защищенном с помощью B2C, нам необходимо показать пользователям AD контент, который имеет отношение к их рабочим характеристикам (в частности, нам нужно фильтровать продукты на основе их рабочей роли), но эта информация недоступна для нас, поскольку процесс регистрация в приложении генерирует новое удостоверение B2C для пользователя (фактически прокси для его удостоверения AD).

Что нам нужно сделать, так это сопоставить исходный идентификатор пользователя AD с новым идентификатором B2C. Другие свойства пользователя AD, такие как Имя и Фамилия, уже сопоставлены, и, похоже, это происходит здесь, в элементе ClaimsProvider нашей настраиваемой политики, через свойство PartnerClaimType:

<OutputClaims>
    <OutputClaim ClaimTypeReferenceId="socialIdpUserId" PartnerClaimType="oid"/>
    <OutputClaim ClaimTypeReferenceId="tenantId" PartnerClaimType="tid"/>
    <OutputClaim ClaimTypeReferenceId="givenName" PartnerClaimType="given_name" />
    <OutputClaim ClaimTypeReferenceId="surName" PartnerClaimType="family_name" />
    <OutputClaim ClaimTypeReferenceId="displayName" PartnerClaimType="name" />
    <OutputClaim ClaimTypeReferenceId="authenticationSource" DefaultValue="contosoAuthentication" />
    <OutputClaim ClaimTypeReferenceId="identityProvider" DefaultValue="AzureADContoso" />
</OutputClaims>

В самом деле, даже кажется, что искомый идентификатор может быть сопоставлен со свойством (oid), но когда мы позже запрашиваем график B2C для пользователя, это свойство oid не возвращается.

Итак - как мы можем сопоставить Object ID пользователя из рабочего каталога AD со свойством в новом созданном удостоверении B2C?


azure azure-active-directory azure-ad-b2c identity-experience-framework claims-based-identity
person Jude Fisher    schedule 27.11.2017    source источник

Ответы (1)


arrow_upward
3
arrow_downward

СОЗДАН 28 ноя 17

В настоящее время идентификатор объекта для пользователя Azure AD (или любого внешнего пользователя) сохраняется в атрибуте «alternateSecurityId» в каталоге Azure AD B2C, но этот встроенный атрибут нельзя запросить через API Graph Azure AD.

Однако вы можете создать настраиваемый атрибут и сопоставить утверждение «oid» от поставщика удостоверений Azure AD с настраиваемым утверждением, связанным с этим настраиваемым атрибутом.

Создание настраиваемого атрибута и его использование в качестве настраиваемого утверждения описано на странице Azure Active Directory B2C: создание и использование настраиваемых атрибутов в политике редактирования настраиваемого профиля.

Для вашего конкретного сценария вам следует:

1: Добавьте <ClaimType />, объявляя настраиваемое утверждение, в базовую политику:

<ClaimType Id="extension_AzureADUserObjectId">
  <DisplayName>Azure AD User Object ID</DisplayName>
  <DataType>string</DataType>
</ClaimType>

2. Сопоставьте утверждение «oid» в техническом профиле «SignInWithContoso»:

<OutputClaims>
  ...
  <OutputClaim ClaimTypeReferenceId="extension_AzureADUserObjectId" PartnerClaimType="oid" />
</OutputClaims>

3. Добавьте идентификаторы приложения и объекта для приложение расширений в технический профиль «AAD-Common», который требуется для чтения и записи настраиваемого утверждения в каталог Azure AD B2C:

<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>

4. Напишите настраиваемое утверждение в техническом профиле «AAD-UserWriteUsingAlternativeSecurityId»:

<PersistedClaims>
  ...
  <PersistedClaim ClaimTypeReferenceId="extension_AzureADUserObjectId" />
</PersistedClaims>

5. Прочтите настраиваемое утверждение в техническом профиле «AAD-UserReadUsingAlternativeSecurityId»:

<OutputClaims>
  ...
  <OutputClaim ClaimTypeReferenceId="extension_AzureADUserObjectId" />
</OutputClaims>

6. Создайте настраиваемое утверждение во всех политиках проверяющей стороны или запросите его через Azure AD Graph API.

ОБНОВЛЕНО 15 февраля 18

Поскольку это объявление от 5 февраля 18, внешний поставщик (т. е. клиент Azure AD) и внешний идентификатор пользователя (т. е. идентификатор объекта пользователя Azure AD) можно прочитать по адресу свойство" userIdentities " объекта объект user в каталоге Azure AD B2C, где свойство «IssuerUserId» содержит кодировку Base64 внешнего идентификатора пользователя:

{
    "userIdentities": [
        {
            "issuer": "contoso.com",
            "issuerUserId": "Mjk2NzdlNTAtY2MwZS00MmU5LWJhNWMtZjFmMDdkZTUwMDhm"
        }
    ]
}
person Chris Padgett    schedule 28.11.2017
comment
Спасибо за подробный ответ. 1,3,4 кристально чистые. №2 - следует ли добавить его в базовый технический профиль Azure AD («AAD-Common» в TrustFrameworkBase) или в технический профиль «SignInWithContoso» в TrustFrameworkExtensions? Я пробовал оба. В первом случае претензии к доверяющей стороне не поступают; последнее приводит к неудачному входу в систему с сообщением server_error. - person Jude Fisher; 28.11.2017
comment
Привет @JcFx. Я отредактировал ответ выше. Это TP SignInWithContoso, к которому вы должны добавить отображение выходного утверждения. Ошибка сервера может быть вызвана тем, что в AAD-Common TP отсутствуют элементы метаданных для приложения расширений, которые я вставил выше на шаге 3. - person Chris Padgett; 29.11.2017
comment
Да, я пропустил шаг 3. Теперь все работает, как ожидалось. Большое спасибо. - person Jude Fisher; 29.11.2017