Как использовать SAML, когда один пользователь хочет олицетворять другого пользователя

У меня есть следующий сценарий:

Пользователь UserA имеет доступ к ApplicationA.

Пользователь имеет доступ к ApplicationB. И ApplicationA, и ApplicationB используют ApplicationI как поставщик удостоверений (пользовательская реализация).

При входе в приложение ApplicationA, UserA хочет, чтобы один вход в ApplicationB использовался как UserB (предположим, что UserB предоставил такое разрешение пользователю UserA).

ApplicationB должен знать, что UserA зарегистрирован как UserB.

Как я могу использовать SAML 2.0 в этом случае? До сих пор все примеры, которые я получил в Интернете о SAML, - это то, что один пользователь пытается использовать Single Sign on как он сам на нескольких сайтах, но не для пользователя, олицетворяющего другого пользователя на другом сайте. В частности, я пытаюсь понять, как я могу использовать SAML Web SSO-профиль с HttpBinding в этом случае.

 0
добавлено
Просмотры: 3
источник
nl ja de
Это звучит как плохое решение. Почему вы хотите использовать UserA для использования учетной записи UserBs? По сути, UserA является UserA и должен быть подписан только как таковой. Если вы объясните причину этого, возможно, мы сможем найти лучшее решение
добавлено автор Stefan Rasmusson, источник
Это о репутации call-центра. Им может потребоваться специальный доступ к учетной записи клиента, чтобы узнать, что они сообщают. Доступ к Приложению контролируется с помощью ответа SAML. SAML - это лишь один из способов, которым эта информация может быть уверенно передана между приложением, которое может иметь разные домены безопасности.
добавлено автор Ian, источник
Единый вход - это когда пользователь с уникальным набором учетных данных обращается к нескольким службам, не вводя свои учетные данные для каждого из них. не могли бы вы объяснить причину такого требования?
добавлено автор Shurmajee, источник

2 ответы

Олицетворение не является неслыханным требованием. Пользовательские данные UserA и UserB могут передаваться в ответ SAML, но потенциально AppA и AppB могут иметь общую модель AuthZ, чтобы вы не получали какую-либо злонамеренную активность.

Так, например, AppA будет аутентифицировать UserA. Когда UserA хочет использовать SSO для AppB и выдавать себя за пользователя UserB, Response будет сгенерирован для UserA с помощью AppA с идентификатором UserB, переданным в атрибуте, где «ImpersonateUser = UserB». UserA будет ПРЕДМЕТОМ ответа. Когда AppB (действующий как SP) проверяет ответ, ему необходимо обеспечить, чтобы UserA разрешалось выдавать себя за пользователя через внутреннее сопоставление авторизации. Или AppB может просто доверять тому, что AppA уже подтвердил, что UserA может выдавать себя за пользователя и создавать сеанс соответствующим образом. Однако это зависит от отношений доверия между AppA и AppB.

НТН, Ян

1
добавлено
источник
Я бы предположил, что AuthnRequst не является местом для этой информации. Вероятно, лучше сделать запрос атрибута обратно в IDP, чтобы получить этот тип информации. В качестве альтернативы вы предоставили бы эту информацию загодя (вне диапазона) и не нуждались бы в обращении к IDP.
добавлено автор Ian, источник
Привет, Ян, спасибо. это решает проблему того, как построить ответ SAML. Не могли бы вы также указать, как в запросе SAML пользователь хочет выдать себя за пользователя UserB? в SAMLRequest Я могу указать только информацию, которая идентифицирует только одного Субъекта или Принципала? Как я могу сказать, что этот запрос предназначен для олицетворения?
добавлено автор 24x7Programmer, источник

Отвечая на ваш вопрос в ответе на Ian, один из способов сообщить IDP, используя AutnRequest, что вы хотите олицетворять другого пользователя, - использовать элемент Extensions в AuthnRequest.

0
добавлено
источник