Я не уверен, что ваш вариант использования вполне соответствует SAML 2.0.
То, что вы описываете как свои бизнес-правила, на самом деле выглядит как сценарий использования для идентификации, а не для управления доступом.
В стандартных случаях использования SAML 2.0 основное внимание уделяется одной стороне, подтверждающей идентичность (провайдеру идентификации), а другой стороне (или сторонам), опирающейся на эти утверждения (провайдеру услуг). Утверждения содержат так называемый идентификатор имени, использование которого заранее согласовано между поставщиком удостоверений и поставщиком услуг.
Эти идентификаторы имен могут быть практически любыми, но в целом они делятся на две категории: временные и постоянные. Идентификатор временного имени полезен только в контексте текущего сеанса (и, по сути, говорит только: «Я знаю, кто этот человек») и имеет тенденцию использоваться для защиты личности принципала при одновременном разрешении привилегированного доступа некоторого типа. Постоянный идентификатор может быть либо непрозрачным (аналогично тому, как OpenID используется для доступа к SO), когда утверждающая сторона может повторно проверять идентичность принципа, не раскрывая их идентичность, в то же время поддерживая динамический, но стабильный общий идентификатор между утверждающей и проверяющей сторонами, или более существенный, такой как UPN Active Directory (который может быть предварительно согласован заранее).
Когда речь идет о паролях, как вы упоминаете в своем вопросе, поставщик услуг (проверяющая сторона) никогда не видит пароль пользователя. Поставщик услуг передает пользователя поставщику удостоверений с запросом аутентификации. Поставщик удостоверений отправляет пользователя обратно поставщику услуг с ответом, который в случае успешной аутентификации содержит утверждение об идентичности пользователя в контексте отношений между поставщиком удостоверений и поставщиком услуг.
В контексте вашего вопроса большое значение имеет то, что SAML 2.0 не позволяет ни создать локальную учетную запись пользователя «приложения», ни связать эту локальную учетную запись пользователя с федеративным удостоверением. Это просто не проблема, которую SAML 2.0 пытается решить.
Теперь вернемся к вашим бизнес-правилам ...
Мне кажется, что вы пытаетесь либо привязать аккаунт, либо зарегистрироваться - я бы подошел к этому так:
- Пользователь посещает приложение, нажимает кнопку, чтобы использовать удостоверение от поставщика удостоверений
- Приложение генерирует запрос аутентификации и направляет пользователя к провайдеру идентификации, выполняющему этот запрос аутентификации
- Поставщик удостоверений либо регистрирует пользователя, либо повторно использует существующий сеанс идентификации, если он у пользователя. IdP создает ответное сообщение, содержащее утверждение о пользователе. В вашем случае это утверждение должно как минимум иметь постоянный идентификатор имени. Поставщик удостоверений направляет пользователя обратно в приложение, передавая ответное сообщение.
- Приложение обрабатывает ответное сообщение. Если существует запись сопоставления для переданного постоянного идентификатора, пользователь распознается из этого сопоставления и входит в систему как локальный пользователь приложения. Если запись сопоставления не существует, пользователю может быть предложено войти в систему локально, и при успешном локальном входе в систему может быть создана запись сопоставления или может быть автоматически создана учетная запись пользователя и пользователю может быть предложено ввести дополнительную информацию (имена, адреса электронной почты). и т. д.) «Корпоративный» сценарий использования: автоматическое связывание или создание учетной записи запрещено, и сопоставление должно существовать заранее.
Что касается содержания сообщений ...
Технический комитет OASIS Security Services имеет загружаемый zip-файл, содержащий обширную документацию по частям схемы XML, включая примеры. Также стоит прочитать документацию по протоколу и профилю, так как они описывают поток сообщений между сторонами, участвующими в диалоге по идентификации.
Есть большое количество презентаций, которые я нашел очень полезными. В частности, Основы SAML v2.0 от Ив Малер помог мне понять, какие проблемы пытается решить SAML v2.0. Эта презентация содержит примеры того, как выглядят утверждения. Обновленная презентация и ссылки на дополнительные ресурсы saml.xml.org .
Я не уверен, что что-то из этого поможет, так как ваш вариант использования, похоже, не тот, что пытается сделать SAML 2.0. При необходимости вы можете добавлять атрибуты и расширения к запросам и ответам, но я не вижу, чтобы многие поставщики удостоверений что-то делали с этими атрибутами и ответами.