Блог

Я использую Graph для запроса профиля пользователя в Azure B2C. Я могу запрашивать пользователей, но я не вижу поле источника для определения источника полномочий. Что это за поле?

В настоящее время я использую предварительный просмотр .28 от Microsoft.График.Бета-пакет NuGet.

И это то, что я вижу в отладчике в разделе Идентификаторы:

Как я могу определить разницу, если это учетная запись Google или учетная запись Azure AD?

Используя Microsoft Graph, это поле issuerId в массиве Identities и возвращается только в бета-версии.

Source не включен в identities массив, а также не включен в свойства.

Как показывает эта проблема с PowerShell, onPremisesSyncEnabled свойство поможет.

Я решил эту проблему, создав пользовательский атрибут, а затем в пользовательских политиках, установив пользовательский атрибут на основе метода регистрации (см. Альтернативное решение ближе к концу).

Здесь довольно хорошо объясняется, как определять пользовательские атрибуты и использовать их с MS Graph API и пользовательскими политиками. Возможно, самое сложное — правильно настроить пользовательскую политику. Я сделал все в TrustFrameworkExtensions.xml . Сначала определите тип утверждения «extension_authoritySource»:

 <ClaimType Id="extension_AuthoritySource">
  <DisplayName>AuthoritySource</DisplayName>
  <DataType>string</DataType>
</ClaimType>
  

Затем <TechnicalProfile Id="Facebook-OAUTH"> я добавил OutputClaim, который устанавливает этот пользовательский атрибут для facebook, но это будет сохраняться только в том случае, если в PersistedClaim внесено, UserWriteUsingAlternativeSecurityId как показано ниже:

 <OutputClaim ClaimTypeReferenceId="extension_AuthoritySource" DefaultValue="Facebook"/>
  

Чтобы сохранить пользовательский атрибут, я добавил следующее в ClaimsProviders:

 <ClaimsProvider>
    <DisplayName>Azure Active Directory</DisplayName>
    <TechnicalProfiles>
      <TechnicalProfile Id="AAD-Common">
        <Metadata>
          <Item Key="ClientId">[b2c-extensions-app application ID]</Item>
          <Item Key="ApplicationObjectId">[b2c-extensions-app application ObjectId]</Item>
        </Metadata>
      </TechnicalProfile>
    
    <!-- Write data during a local account sign-up flow. -->
    <TechnicalProfile Id="AAD-UserWriteUsingLogonEmail">
      <PersistedClaims>
        <PersistedClaim ClaimTypeReferenceId="extension_AuthoritySource" DefaultValue="local"/>
      </PersistedClaims>
    </TechnicalProfile>

      <TechnicalProfile Id="AAD-UserWriteUsingAlternativeSecurityId">
        <PersistedClaims>
          <PersistedClaim ClaimTypeReferenceId="extension_AuthoritySource" DefaultValue="social"/>
        </PersistedClaims>
      </TechnicalProfile>
  </TechnicalProfiles>
</ClaimsProvider>
  

Обратите внимание, что при вышеуказанных регистрациях по электронной почте всегда будет установлено значение «local», в то время UserWriteUsingAlternativeSecurityId как оно устанавливается как «social», но перезаписывается утверждением вывода из facebook.

Я думаю, что UserWriteUsingLogonEmail это используется только при регистрации по электронной почте, тогда UserWriteUsingAlternativeSecurityId как потенциально может использоваться несколькими объединенными логинами, хотя на данный момент я использую только facebook.

Альтернатива без пользовательского атрибута

В качестве альтернативы, если вы не используете пользовательские политики или не можете использовать описанный выше подход по другой причине, вы можете использовать MS Graph API и посмотреть в массиве «идентификаторы», который содержит тип входа. Итак, для данного пользователя ПОЛУЧАЕМ: https://graph.microsoft.com/v1.0/users/[Users objectID Guid]?$select=identities

В этом массиве вы можете найти для локальной регистрации:

 {
  "signInType": "emailAddress",
  "issuer": "[yourdomain].onmicrosoft.com",
  "issuerAssignedId": "[email]"
}
  

и для facebook:

 {
  "signInType": "federated",
  "issuer": "facebook.com",
  "issuerAssignedId": "[number]"
}
  

У каждого пользователя также есть элемент «userPrincipalName» в массиве идентификаторов, поэтому вам потребуется некоторая логика для перебора массива и поиска только того signInType, который вы хотите поддерживать. Еще одна причина, по которой вы предпочитаете использовать пользовательский атрибут и самостоятельно устанавливать источник полномочий.