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

Question

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

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

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

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

Answer 1

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

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

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

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

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

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

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

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

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

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

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

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

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