Утверждение SAML с именем пользователя/паролем - каковы сообщения на самом деле?

Мне нужно создать некоторые утверждения SAML 2.0, и у меня возникли проблемы с поиском того, как должен выглядеть XML. Большая часть документации, похоже, связана с использованием определенных инструментов, а не сообщений. У меня есть схемы с множеством возможностей, но я не могу найти пример того, как на самом деле выглядят соответствующие сообщения на практике.

В бизнес-правиле говорится: чтобы создать общий идентификатор, пользователь сообщает системе A свое имя пользователя и пароль в системе B. Системе A необходимо передать эту информацию (вместе с некоторыми демографическими данными) в систему B. Система B проверяет и передает обратно уникальный идентификатор, который затем может использоваться для обращения к этому пользователю.

Может ли кто-нибудь дать мне пример того, какие утверждения SAML 2.0 будут похожи на эту информацию?

FWIW, я использую С# и должен передавать XML вокруг способами, которые исключают использование стороннего инструмента.

Ответ 1

Я не уверен, что ваш вариант использования - это то, что делает SAML 2.0.

То, что вы описываете как ваши бизнес-правила, на самом деле выглядит как пример использования для обеспечения идентификации, а не для управления доступом.

В стандартных случаях использования SAML 2.0 основное внимание уделяется одной стороне, утверждающей личность (поставщик удостоверений), и другой стороне (или сторонам), полагающейся на эти утверждения (поставщик услуг). Утверждения содержат то, что называется идентификатором имени, использование которого заранее согласовано между поставщиком удостоверений и поставщиком услуг.

Эти идентификаторы имен могут быть практически любыми, но они в целом подразделяются на две категории: переходные и постоянные. Идентификатор переходного имени полезен только в контексте текущего сеанса (и, по сути, только говорит: "Я знаю, кто этот человек" ) и, как правило, используется для защиты идентификатора принципала при разрешении доступа к привилегированному типу определенного типа. Постоянный идентификатор может быть непрозрачным (аналогично тому, как OpenID используется для доступа к SO), где заявляющая сторона может неоднократно проверять подлинность принципа, не раскрывая их идентификацию, сохраняя динамический, но стабильный общий идентификатор между утверждающими и полагающимися сторонами или более существенные, такие как UPN Active Directory (который может быть заранее согласован заранее).

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

В контексте вашего вопроса большое значение имеет то, что SAML 2.0 не предоставляет способ создать локальную учетную запись "приложение" или ссылку на эту учетную запись локального пользователя на федеративный идентификатор. Это просто не проблема, которую пытается решить SAML 2.0.

Теперь вернемся к вашим бизнес-правилам...

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

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

Что касается содержимого сообщений...

Технический комитет служб безопасности OASIS имеет доступ к загрузке zip файла с подробной документацией о частях схемы XML, включая примеры. Также полезно ознакомиться с протокольной и профильной документацией, поскольку они описывают поток сообщений между сторонами, участвующими в сеансе идентификации.

Есть большое количество презентаций, плавающих вокруг, которые я нашел очень полезными. В частности, Основы SAML v2.0 от Eve Maler помогли мне начать понимать, какие проблемы SAML v2.0 пытались решать. Эта презентация включает примеры этих утверждений. Существует обновленная презентация и ссылки на дополнительные ресурсы на saml.xml.org.

Я не уверен, что хоть какое-то из этих способов поможет, поскольку ваш прецедент не кажется тем, что пытается сделать SAML 2.0. Вы можете добавлять атрибуты и расширения по мере необходимости к запросам и ответам, но я не вижу, чтобы многие поставщики удостоверений что-либо делали с этими атрибутами и ответами.