IdM - Сценарии

Данная страница перенесена в архив.
Активная разработка продукта прекращена.

Существует несколько сценариев построения доверительных отношений между сервисами в облаке и Центрами идентификации (ЦИ). Сценарии можно разделить на два больших класса: пассивный (на основе веб-браузера) и активный (на основе смарт-клиента). Различия заключается в используемых протоколах. Так как обозреватель не поддерживает протокол WS-Trust для получения маркера безопасности, его работа имитируется стандартными возможностями HTTP (GET, POST, перенаправление, и cookies).

Активный сценарий

Активный сценарий

На рисунке представлен пример взаимодействия веб-сервиса (RP) и активного клиента, который хочет использовать данный сервис. Веб-сервис представляет клиенту политику, в которой описаны его адреса, привязки, контракты. Помимо этого в политике указан набор необходимых сервису утверждений, например, имя, адрес электронной почты, роль. А также адрес ЦИ, где клиент может получить утверждения. После получения политики (1), клиент знает, куда обратиться для аутентификации. Клиент отправляет запрос к ЦИ на утверждения (2), необходимые доверяющей стороне. В задачи ЦИ входит: аутентифицировать пользователя и выпустить электронный идентификатор, с требуемым набором утверждений. В конце (3) клиент делает запрос доверяющей стороне, пересылая электронный идентификатор в заголовке SOAP сообщения. Доверяющая сторона теперь будет получать утверждения с каждым запросом к ней, и отклонять запросы, которые не содержат электронный идентификатор от доверенного издателя.

Пассивный сценарий

Пассивный сценарий

Описанный выше сценарий может быть реализован в приложениях на основе обозревателя (называемых пассивным сценарием). На рисунке показан пример сценария. Пользователь в обозревателе открывает веб-сайт, использующий модель идентификации на основе утверждений (1). Веб-приложение перенаправляет обозреватель к ЦИ, где пользователь может быть аутентифицирован (2). На рисунке ЦИ «обёрнут» в небольшое веб-приложение, которое читает пришедший запрос и аутентифицирует пользователя стандартными механизмами HTTP. Затем будет создан электронный идентификатор и вставлен небольшой java-скрипт, который заставит обозревателя сделать HTTP-POST, содержащий электронный идентификатор для доверяющей стороны(3). Тело POST содержит утверждения, требуемые доверяющей стороне. Будет естественно сохранить утверждения пользователя в cookie, чтобы избавить его от необходимости аутентифицироваться при каждом новом запросе.

Сценарий федерации

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

Сценарий федерации

Сценарий начинается схожим образом: пользователь на предприятии Х обращается к приложению на предприятии Y, и узнает требования к электронному идентификатору. Приложение сконфигурировано так, чтобы доверять ЦИ предприятия Y (ЦИ-Y). Поэтому пользователь обращается к ЦИ-Y, чтобы узнать его требования к электронному идентификатору. Клиент понимает, что он может аутентифицироваться через ЦИ в своей организации, и получить от него электронный идентификатор (1). Электронный идентификатор содержит необходимый ЦИ-Y набор утверждений и в нем описано, где клиент был аутентифицирован. Но доверяющая сторона не примет этот идентификатор – так как он выпущен не доверенной приложению стороной. Поэтому клиент отправляет идентификатор ЦИ-Y, который сконфигурирован доверять ЦИ-X (2). Поэтому ЦИ-Y проверит пришедший идентификатор, и выпустит на его основе новый электронный идентификатор, который позволит пользователю получить доступ к приложению (3). При кросс-ЦИ авторизации появляется понятие трансформации электронных идентификаторов, так как один домен ничего не знает о пользователях и авторизационных утверждениях другого домена. ЦИ-Y, по заданным администратором правилам, может преобразовать утверждения, выпущенные ЦИ-X, в утверждения, которые понимает доверяющая сторона. Так может происходить, например, преобразование ролей пользователя. Либо ЦИ-X может отклонять все электронные идентификаторы со значения утверждений, не удовлетворяющих некоторым правилам.

 

Отметим несколько преимуществ сценария, когда на стороне доверяющей стороны развернут ЦИ. Во-первых, ЦИ-Y может быть использован для аутентификации в обоих сценариях: пассивного и активного. Во-вторых, это позволит выполнять основную массу работы по аутентификации на специализированном сервере, а не на сервере приложения. В-третьих, это позволит приложению принимать идентификаторы, содержащие лишь необходимую данному приложению информацию (лишь решение о допуске пользователя, например), вместо более сложных в аутентификации электронных идентификаторов, выпускаемых ЦИ-X.

Купить

Вход

Подписка