NotOnOrAfter в SubjectConfirmationData и условия и SessionNotOnOrAfter

В спецификации SAML2 есть несколько мест в утверждении, где можно указать время жизни.

Элемент <SubjectConfirmationData> содержит атрибут NotOnOrAfter.
Элемент <Conditions> содержит атрибут NotOnOrAfter.
Элемент <AuthnStatement> содержит атрибут SessionNotOnOrAfter.

В чем смысл каждого из них? Как они соотносятся друг с другом?

В частности, какие из них необходимо проверить, когда...

... потребление входящего ответа Saml2Response с использованием веб-единого входа
... установление сеанса приложения в SP
... обновление (продление) сеанса приложения в SP
... пересылка утверждения в веб-службу, действие от имени субъекта (как описано @Thuan)
... выдача одиночного запроса на выход idp, чтобы гарантировать, что idp все еще знает о сеансе?

Каждый из NotOnOrAfters описан в базовой спецификации SAML2. Я включил части, которые я могу найти, которые описывают эти атрибуты здесь.

SubjectConfirmationData/@NotOnOrAfter

Временной момент, когда субъект больше не может быть подтвержден. Значение времени кодируется в формате UTC, как описано в разделе 1.3.3.

Обратите внимание, что период времени, указанный дополнительными атрибутами NotBefore и NotOnOrAfter, если они имеются, СЛЕДУЕТ относиться к общему периоду действия утверждения, указанному атрибутами NotBefore и NotOnOrAfter. Если оба атрибута присутствуют, значение NotBefore должно быть меньше (раньше) значения NotOnOrAfter.

Условия /@NotOnOrAfter

Определяет момент времени, в течение которого это утверждение истекло. Значение времени кодируется в формате UTC, как описано в разделе 1.3.3.

Атрибуты NotBefore и NotOnOrAfter определяют временные ограничения на достоверность утверждения в контексте его профиля (ов) использования. Они не гарантируют правильности или точности заявлений в утверждении на протяжении всего срока действия. Атрибут NotBefore определяет момент времени, с которого начинается интервал действия. Атрибут NotOnOrAfter указывает момент времени, в течение которого интервал действия закончен. Если значение для NotBefore или NotOnOrAfter опущено, то считается неуказанным. Если атрибут NotBefore не указан (и если все остальные условия, которые поставляются, оцениваются как Действительные), то утверждение является Действительным в отношении условий в любое время до момента времени, указанного в Атрибут NotOnOrAfter. Если атрибут NotOnOrAfter не указан (и если все остальные условия, которые поставляются, оцениваются как Действительные), утверждение является Действительным в отношении условий с момента времени, указанного атрибутом NotBefore, без истечения срока действия. Если ни один атрибут не указан (и если какие-либо другие условия, которые поставляются, оцениваются как Действительные), утверждение является действительным в отношении условий в любое время.

Если оба атрибута присутствуют, значение NotBefore ДОЛЖНО быть меньше (раньше) значения для NotOnOrAfter.

AuthnStatement/@SessionNotOnOrAfter

Указывает верхнюю границу сеансов с объектом, полученным из прилагаемого утверждения. Значение времени кодируется в UTC, как описано в разделе 1.3.3. Между этим атрибутом и обязательным атрибутом NotOnOrAfter не существует необходимой связи, которая может присутствовать в утверждении. Он оставил профили для предоставления конкретных правил обработки для полагающихся сторон на основе этого атрибута.

Ответ 1

Я перекрестил этот вопрос в список рассылки SAML-dev и получил ответ от Скотта Кантора, который был редактором на технические характеристики.

Время в <SubjectConfirmationData> показывает, сколько времени может быть привязано к объекту. В Web SSO, где обычно используется метод подтверждения субъекта "носитель", это означает, что в течение этого времени мы можем верить, что утверждение применяется к тому, которое обеспечивает утверждение. Утверждение может быть действительным в течение более длительного времени, но мы должны создать сеанс в течение этого временного интервала. Это описано в разделе Веб-профиль SSO в разделе 4.1.4.3. Время в <SubjectConfirmationData> должно находиться в пределах интервала в <Conditions>.
Временем в <Conditions> является справедливость всего утверждения. Его нельзя употреблять после этого времени. Нет ничего, что помешало бы сеансу пользователя на SP расшириться за этот момент времени.
SessionNotOnOrAfter - это нечто совершенно иное, не связанное напрямую с временем жизни утверждения или субъекта. Это параметр, который idp может использовать для управления длительностью сеанса SP. Обратите внимание, что этот параметр определен, что он ДОЛЖЕН обрабатываться SP в соответствии со спецификацией SAML2Core, но далеко не все реализации SP. Пример реализации, который делает, как обычно, Shibboleth, который всегда будет учитывать появление этого параметра. При использовании Single Logout этот параметр более критичен, поскольку он синхронизирует таймаут сеанса как с SP, так и с Idp, чтобы гарантировать, что SP не выдаст запрос на выход для сеанса, который больше не известен Idp.

Ответ 2

По моему мнению, только авторы спецификации Saml2 могут четко ответить на этот вопрос. Я также думаю, что они могут написать книгу на 10000 страниц, чтобы объяснить многие "почему" вопросы о спецификации, которую люди просили годами. Во всяком случае, исходя из моих ограниченных знаний и случаев использования, с которыми я столкнулся, моя интерпретация этих свойств такова:

Посмотрим на пример:

SSO: SP получает подтверждение от IdP и регистрирует пользователя.
Точка загрузки: SP сохраняет утверждение как токен начальной загрузки для последующего использования.
SP использует токен bootstrap для обмена для токена ActAs, чтобы он мог использоваться для доступа к другой веб-службе. Он также будет кэшировать токен для дальнейшего использования, чтобы не обмениваться новым токеном часто, пока этот токен все еще действителен.

В случае (1) утверждение справедливо тогда и только тогда, когда действительны оба объекта SubjectConfirmationData.NotOnOrAfter и условия. NOTOnOrAfter. Поскольку утверждение действительно, SP создаст для пользователя сеанс входа в систему. Как долго сеанс должен быть указан значением SessionNotOnOrAfter.

Как насчет 3? Я бы сказал, что токен считается действительным, когда условия .NotOnOrAfter все еще действительны. По словам Скотта Кантора: "Правила обработки специфичны для профилей и контекста использования". Источник: https://lists.internet2.edu/sympa/arc/mace-opensaml-users/2011-05/msg00007.html В этой связи они также обсуждали времена жизни Субъекта и Условия, в которых Условия обычно имеют более длительный срок жизни, чем у Субъекта.