Как SAML решает SSO?

Question

После прочтения нескольких статей о SAML, в том числе «SAML для чайников» и статьи Wiki SAML, я все еще не совсем понимаю, как SAML фактически решает проблему SSO. Предположим, я беру что-то вроде учетной записи Google в качестве примера. Я понимаю, что если я перейду на GMail и SAML, я буду перенаправлен на IDP, который, скажем, является авторитетом входа в Google. Мой браузер затем отправляется туда с перенаправлением, и меня просят войти в систему. После предоставления правильной информации для входа я возвращаюсь к GMail с ответным сигналом и SAML, зашифрованным с помощью закрытого ключа входа в систему Google, который затем аутентифицируется с использованием GMail's открытый ключ, таким образом, подтверждая, что я, по сути, я говорю.

Что меня пугает, так это то, что это, похоже, решает проблему подписания в первый раз или в одно приложение, но я не понимаю, что происходит, когда я перехожу на Google Диск. Даже если мой браузер сохраняет токен/ответ SAML в качестве файла cookie, мне нужно будет снова войти в него после истечения срока действия токена, который, как я прочитал, - это что-то вроде 2 минут спустя. Более того, даже в том же приложении запросы на разделение ресурсов или конечных точек кажутся похожими на то, что они будут тайм-аутом одинаково.

Единственный намек, который у меня есть, заключается в том, что согласно статье wiki, шаг 1 имеет целевой ресурс на проверке SP для «действительного контекста безопасности». Однако, если GMail и Drive являются отдельными приложениями, которые не взаимодействуют друг с другом, как бы Диск знал, что у меня уже есть действующий контекст безопасности?

Вопросы:

1. После начальной аутентификации, какая информация должна быть отправлена ​​с будущими запросами к той же или другой прикладной/конечной точки? Например, возможно, утверждение SAML сохранено и resent с каждым запросом.
2. Как эта информация защищена/проверена?
3. Какие тайм-ауты связаны с SSO SAML и как применяются таймауты на обеих сторонах SP и IDP?

Answer 1

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

Теперь idp имеет активный сеанс благодаря файлу cookie в домене idp. Это позволяет idp отвечать на Google Drive с новым утверждением, полученным из информации о сохраненных сеансах.

Вы правы, что каждое утверждение обычно действует только в течение нескольких минут, но это не проблема, так как idp может создать новое утверждение для каждого приложения.

Для тайм-аутов: Idp может установить условие SessionNotOnOrAfter в утверждении, чтобы сообщить SP, что он должен завершить сеанс в данный момент времени.