Почему стойкие идентификаторы SAML используются как «механизм защиты конфиденциальности»?

Question

Раздел 8.3.7 от основной спецификации SAML утверждает, что формат persistent NameID используется для защиты частной жизни:

Стойкие идентификаторы предназначены в качестве механизма защиты частной жизни; как таковые, они НЕ ДОЛЖНЫ использоваться в открытом тексте с поставщиками, отличными от поставщиков, которые установили общий идентификатор . Кроме того, они НЕ ДОЛЖНЫ появляться в файлах журналов или подобных местах без соответствующих средств контроля и защиты.

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

Каким образом уникальный идентификатор NameID per-SP является «механизмом защиты конфиденциальности»? В частности, какие векторы атаки были бы смягчены с помощью поля NameID persistent над другим типом (в частности, когда существуют защиты, такие как правильные ограничения аудитории и подписи)?

Answer 1

Это механизм защиты конфиденциальности, поскольку он не передает ваш реальный идентификатор от IdP к SP. Между тем, тип EmailIDID, например, переносит вашу электронную почту с IdP на SP.

Один онлайн-ресурс, который я могу найти, что объясняет это довольно хорошо, - http://docs.oasis-open.org/security/saml/Post2.0/sstc-saml-tech-overview-2.0.html раздел 5.4.3. Федерация, использующая постоянные идентификаторы псевдонимов.

Обработка заключается в следующем:

1. пользователь пытается получить доступ к ресурсу на cars.example.co.uk. У пользователя нет текущего сеанса входа в систему (то есть контекста безопасности) на этом сайте и ему неизвестно. Ресурс, к которому пользователь пытался получить доступ, сохраняется как информация RelayState.

2. Поставщик услуг использует привязку перенаправления HTTP, чтобы отправить пользователя в службу единого входа в провайдере идентификации (авиакомпания.example.com). Переадресация HTTP включает в себя сообщение SAML, запрашивающее, чтобы поставщик удостоверений предоставлял утверждение с использованием постоянного идентификатора имени для пользователя. Поскольку поставщик услуг желает, чтобы IdP имел гибкость для генерации нового идентификатора для пользователя, если он еще не существует, SP устанавливает атрибут AllowCreate в элементе NameIDPolicy на «true».

3. Пользователю будет предложено предоставить действительные учетные данные.
4. Пользователь предоставляет действительные учетные данные, идентифицирующие себя как john, и локальный контекст безопасности создается для пользователя в IdP.
5. Служба единого входа ищет пользователя john в своем хранилище удостоверений и, видя, что это разрешает атрибут AllowCreate, создает постоянный идентификатор имени (61611), который будет использоваться для сеанса у поставщика услуг. Затем он создает подписанное утверждение SSO для веб-SSO, в котором субъект использует формат идентификатора переходного имени. Имя john не содержится нигде в утверждении. Обратите внимание, что в зависимости от партнерских соглашений утверждение может также содержать инструкцию атрибута, описывающую атрибуты идентификации пользователя (например, уровень их членства).
6. Браузер, связанный с действием пользователя или выполнением сценария «авто-отправки», выдает запрос HTTP POST для отправки формы в службу обслуживания Assertion Service Service.
7. Служба подтверждения обслуживания поставщика услуг cars.example.co.uk проверяет цифровую подпись в ответе SAML и подтверждает утверждение SAML. Затем указанный идентификатор имени используется для определения того, была ли установлена ​​предыдущая федерация. Если была установлена ​​предыдущая федерация (поскольку идентификатор имени сопоставляется с локальной учетной записью), переходите к шагу 9. Если федерация не существует для постоянного идентификатора в утверждении, тогда SP должен определить локальный идентификатор, которому он должен быть назначены. Пользователю будет предложено предоставить местные учетные данные в SP. По желанию пользователя сначала можно спросить, хочет ли он объединить две учетные записи.
8. Пользователь предоставляет действительные учетные данные и идентифицирует свою учетную запись на SP как jdoe. Идентификатор постоянных имен затем сохраняется и регистрируется в учетной записи jdoe вместе с именем поставщика удостоверений, который создал идентификатор имени.
9. Для пользователя jdoe создается локальный сеанс регистрации, и затем выполняется проверка доступа, чтобы установить, имеет ли пользователь jdoe правильное разрешение на доступ к требуемому ресурсу на веб-сайте cars.example.co.uk (URL-адрес ресурса был извлекается из информации о состоянии идентифицированного RelayState информации. Если проверка доступа проходит, желаемый ресурс возвращается в браузер.

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