Как сохранить контекст пользователя с токеном AAD B2C

Я использую AAD B2C для защиты приложения JavaScript и поддержки веб-служб. Пользователи могут быть связаны с несколькими компаниями, поэтому я планирую использовать раскрывающийся список и позволять пользователю выбирать, в каком контексте они хотят действовать.

Серверная веб-служба должна получать «контекст» … поэтому я чувствую, что мне нужно добавить значение в токен AAD B2C после аутентификации пользователя … или мне нужно перезвонить в AAD B2C с ценность как-то.

Я не могу найти никакой документации, подтверждающей, что это возможно.

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

Привет @Kye. Будет ли один и тот же пользователь входить в систему, используя разные идентификационные данные для разных компаний?   —  person Kye    schedule 11.08.2019

Нет. Они войдут в систему, используя единую личность.   —  person Kye    schedule 12.08.2019

См. также:  Шифрование на стороне сервера и шифрование на стороне клиента - Amazon S3
Понравилась статья? Поделиться с друзьями:
IT Шеф
Комментарии: 2
  1. Kye

    Вы не можете просто «добавить ценность» к токену. Токен создается и подписывается MS, а не вашим приложением.

    Но вы можете определить собственное утверждение и включить его в токен. Допустим, вы назовете его Контексты, и это будет список идентификаторов или названий компаний, к которым у пользователя есть доступ. После успешного входа в систему токен с этим утверждением возвращается в ваш js, и вы можете проанализировать его, чтобы отдельные элементы (компании) отображались в раскрывающемся списке. После того, как пользователь выбрал предпочтительный контекст из раскрывающегося списка, вы передаете его своей серверной веб-службе в качестве дополнительного параметра, а не как часть токена.

    Управлять свойством / утверждением Contexts можно с помощью вызовов Graph — я подозреваю, что вы не хотите позволять самим пользователям добавлять туда все, что они хотят.

  2. Kye

    Единственный способ реализовать этот сценарий, когда у потребителя есть соответствующие права доступа к нескольким арендаторам в рамках вашего сценария, — это использовать Пользовательские политики:

    1. Соберите учетные данные пользователей и подтвердите
    2. Вызов REST API, чтобы отправить обратно разделенный запятыми список помещений, к которым у пользователя есть доступ.
    3. Отображение самоутвержденной страницы с двумя утверждениями B2C в текстовых полях. Один должен быть заполнен списком, разделенным запятыми, из 2) с помощью InputClaims.
    4. Настройте эту страницу, включив JavaScript, используя JS для рендеринга раскрывающегося списка с его перечислением из заполненного текстового поля из 3.
    5. Когда пользователь выбирает из раскрывающегося списка, отправьте результат с помощью JS в другое текстовое поле, которое было отображено.
    6. Используйте CSS, чтобы скрыть 2 текстовых поля.
    7. Когда пользователь отправляет страницу, используйте профиль ValidationTechnical, чтобы отправить обратно введенные пользователем данные в REST API, чтобы убедиться, что значение находится в их авторизованном списке аренды.
    8. Вставьте имя клиента в токен, используя раздел Outputclaims элемента RelyingParty.
    9. Теперь приложение может знать, какую арендную плату отображать, с правильными правами доступа.
Добавить комментарий

;-) :| :x :twisted: :smile: :shock: :sad: :roll: :razz: :oops: :o :mrgreen: :lol: :idea: :grin: :evil: :cry: :cool: :arrow: :???: :?: :!: