Как предварительно создать «бизнес-клиентов» в AD B2C - PullRequest
Новая
       9

Как предварительно создать «бизнес-клиентов» в AD B2C

0 голосов
/ 16 февраля 2019

Я создаю встроенное веб-приложение для предоставления пользователям моего приложения LOB.Большинство моих клиентов являются «бизнес-клиентами», то есть они обычно перенаправляются на общую конечную точку v1 с помощью собственной политики, которая позволяет им выполнять аутентификацию на своем собственном клиенте AAD.Проблема в том, что новые пользователи также нуждаются в последующей подготовке в LOB-приложении (создание пользователя БД, назначение некоторых разрешений и т. Д.).

То, что я хотел бы сделать в рамках адаптации, это вызвать graphAPI, чтобы создать учетную запись федеративного пользователя в b2c, а затем новый объектный идентификатор пользователя, который возвращается для последующей настройки, специфичной длямое приложение LOB.В идеале, когда пользователь прибывает в первый раз, он будет перенаправлен на авторизацию против своего собственного AAD, затем сопоставляется с предварительно созданным пользователем в b2c и, наконец, попадает в LOB-приложение с уже предоставленным и готовым objectId.

Это поддерживаемый сценарий с творческим использованием пользовательских политик и graphAPI?

Спасибо, Марк

1 Ответ

0 голосов
/ 18 февраля 2019

Для этого доступны следующие параметры:

  1. Создайте пользователя локальной учетной записи с внешним адресом электронной почты и свяжите идентификатор внешнего пользователя с этим пользователем локальной учетной записи.
  2. Создайтепользователь внешнего аккаунта с идентификатором внешнего пользователя.

1.Создайте пользователя локальной учетной записи с внешним адресом электронной почты

С помощью API-интерфейса Azure AD Graph вы можете создать пользователя локальной учетной записи со свойством signInNames объект пользователь устанавливается на адрес электронной почты внешнего пользователя: 

{
  "accountEnabled": false,
  "creationType": "LocalAccount",
  "displayName": "John Smith",
  "passwordProfile": {
    "password": "a-strong-random-password",
    "forceChangePasswordNextLogin": false
  }
  "signInNames": [
    {
      "type": "emailAddress",
      "value": "john.smith@company.com"
    }
  ]
}

Примечание: Я рекомендую свойство accountEnabled объекта user объект имеет значение true , чтобы конечный пользователь не мог войти в систему с паролем локальной учетной записи.

Используя пользовательскую политику, вы можете добавитьновая логика для поиска локального пользователя учетной записи с использованием внешнего адреса электронной почты и добавления идентификатора внешнего пользователя для этого локального пользователя учетной записи, например: 

...
<!--
      Find the external account user using the external user identity.
-->
<OrchestrationStep Order="16" Type="ClaimsExchange">
  <Preconditions>
    <Precondition Type="ClaimEquals" ExecuteActionsIf="true">
      <Value>authenticationSource</Value>
      <Value>localAccountAuthentication</Value>
      <Action>SkipThisOrchestrationStep</Action>
    </Precondition>
  </Preconditions>
  <ClaimsExchanges>
    <ClaimsExchange Id="AADUserReadUsingAlternativeSecurityId" TechnicalProfileReferenceId="AAD-UserReadUsingAlternativeSecurityId-NoError" />
  </ClaimsExchanges>
</OrchestrationStep>
<!--
      If the external account user hasn't been found, then find the local account user using the external email address.
-->
<OrchestrationStep Order="17" Type="ClaimsExchange">
  <Preconditions>
    <Precondition Type="ClaimEquals" ExecuteActionsIf="true">
      <Value>authenticationSource</Value>
      <Value>localAccountAuthentication</Value>
      <Action>SkipThisOrchestrationStep</Action>
    </Precondition>
    <Precondition Type="ClaimsExist" ExecuteActionsIf="true">
      <Value>objectId</Value>
      <Action>SkipThisOrchestrationStep</Action>
    </Precondition>
  </Preconditions>
  <ClaimsExchanges>
    <ClaimsExchange Id="AADUserReadUsingEmailAddress" TechnicalProfileReferenceId="AAD-UserReadUsingEmailAddress-NoError" />
  </ClaimsExchanges>
</OrchestrationStep>
<!--
      If an account user hasn't been found, then create an external account user with the external user identity.
-->
<OrchestrationStep Order="18" Type="ClaimsExchange">
  <Preconditions>
    <Precondition Type="ClaimEquals" ExecuteActionsIf="true">
      <Value>authenticationSource</Value>
      <Value>localAccountAuthentication</Value>
      <Action>SkipThisOrchestrationStep</Action>
    </Precondition>
    <Precondition Type="ClaimsExist" ExecuteActionsIf="true">
      <Value>objectId</Value>
      <Action>SkipThisOrchestrationStep</Action>
    </Precondition>
  </Preconditions>
  <ClaimsExchanges>
    <ClaimsExchange Id="AADUserWriteUsingAlternativeSecurityId" TechnicalProfileReferenceId="AAD-UserWriteUsingAlternativeSecurityId" />
  </ClaimsExchanges>
</OrchestrationStep>
<!--
      If the local account user has been found using the external email address, then add the external user identity to this local account user.
-->
<OrchestrationStep Order="19" Type="ClaimsExchange">
  <Preconditions>
    <Precondition Type="ClaimEquals" ExecuteActionsIf="true">
      <Value>authenticationSource</Value>
      <Value>localAccountAuthentication</Value>
      <Action>SkipThisOrchestrationStep</Action>
    </Precondition>
    <!-- The following claim is output from the AAD-UserWriteUsingAlternativeSecurityId technical profile. -->
    <Precondition Type="ClaimsExist" ExecuteActionsIf="true">
      <Value>newUserCreated</Value>
      <Action>SkipThisOrchestrationStep</Action>
    </Precondition>
    <!-- The following claim is output from the AAD-UserReadUsingEmailAddress-NoError technical profile. -->
    <Precondition Type="ClaimsExist" ExecuteActionsIf="false">
      <Value>existingUserFoundByEmail</Value>
      <Action>SkipThisOrchestrationStep</Action>
    </Precondition>
  </Preconditions>
  <ClaimsExchanges>
    <ClaimsExchange Id="AADUserWriteUserIdentity" TechnicalProfileReferenceId="AAD-UserWriteUserIdentity" />
  </ClaimsExchanges>
</OrchestrationStep>
...

2.Создание пользователя внешней учетной записи с идентификатором внешнего пользователя

С помощью API-интерфейса Azure AD Graph вы можете создать пользователя внешней учетной записи со свойством userIdentities объект пользователь устанавливается в качестве идентификатора объекта внешнего пользователя: 

{
  "accountEnabled": false,
  "displayName": "John Smith",
  "mailNickname": "john.smith",
  "otherMails": [
    "john.smith@company.com"
  ],
  "userIdentities": [
    {
      "issuer": "https://sts.windows.net/{their-tenant-object-id}/",
      "issuerUserId": "{their-user-object-id}"
    }
  ],
  "userPrincipalName": "{guid}@{your-tenant-name}.onmicrosoft.com"
}

, где IssueUserId должен быть установлен в кодировку base64 для идентификатора объекта идентификатора объекта.внешний пользователь.

Примечание: В техническом профиле Azure AD OpenID Connect может потребоваться изменить сопоставление заявки для заявки socialIdpUserId из подпункта утверждение к утверждению oid , так что оно соответствует свойству userIdentities.issuerUserId объекта user : 

<OutputClaim ClaimTypeReferenceId="socialIdpUserId" PartnerClaimType="oid" />
...