В файле метаданных SAML существует несколько определенных форматов NameID, например:
урны: Mace: Шибболет: 1.0: nameIdentifier
Урна: Oasis: имена: дц: SAML: 1.1: NameID-формат: не определено
урна: оазис: имена: дц: SAML: 2,0: NameID формат: переходная
Кто-нибудь может объяснить, для чего они используются? В чем отличия?
обратитесь к разделу 8.3 этого основного файла SAML спецификации оазиса SAML.
SP и IdP обычно сообщают друг другу о предмете. Этот предмет должен быть идентифицирован с помощью идентификатора NAME-идентификатора, который должен быть в некотором формате, чтобы другая сторона могла идентифицировать его на основе формата.
Все эти
1.urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified [default]
2.urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress
3.urn:oasis:names:tc:SAML:2.0:nameid-format:persistent
4.urn:oasis:names:tc:SAML:2.0:nameid-format:transient
- формат идентификаторов имен.
Переходный период для [раздел 8.3.8 < SAML Core]
Указывает, что содержимое элемента является идентификатором с переходной семантикой и ДОЛЖНЫ относиться как к непрозрачным и временным ценность полагающейся стороной.
Unspecified может использоваться, и его чисто зависит от реализации объектов по собственному желанию.
1 и 2 являются SAML 1.1, поскольку эти URI являются частью стандарта OASIS SAML 1.1. Раздел 8.3 связанного PDF для стандарта OASIS SAML 2.0 объясняет это:
По возможности существующий URN используется для указания протокола. В случае протоколов IETF используется URN самого текущего RFC, который определяет протокол. Ссылки на URI, созданные специально для SAML, имеют одну из следующих основ в соответствии со спецификацией, в которой они были впервые введены:
urn:oasis:names:tc:SAML:1.0: urn:oasis:names:tc:SAML:1.1: urn:oasis:names:tc:SAML:2.0:
Об этом я думаю, вы можете ссылаться на http://docs.oasis-open.org/security/saml/Post2.0/sstc-saml-tech-overview-2.0.html.
Вот мое понимание об этом, с примером использования федерации удостоверений, чтобы дать подробную информацию для этих концепций:
IdP предоставляет постоянные идентификаторы, они используются для привязки к локальным учетным записям в SP, но они идентифицируют как профиль пользователя для конкретной службы каждый отдельно. Например, постоянные идентификаторы похожи на: johnForAir, jonhForCar, johnForHotel, все они предназначены только для одной указанной службы, так как ей необходимо связать свой локальный идентификатор в сервисе.
Идентификаторы переходных процессов - это то, что IdP сообщает SP, что пользователям сеанса предоставлен доступ к ресурсу в SP, но идентификаторы пользователей не предлагают SP на самом деле. Например, утверждение, подобное "Анонимность (Idp не сообщает SP, кто он), имеет разрешение на доступ/ресурс на SP". SP получил его и позволил браузеру получить к нему доступ, но до сих пор не знает реальное имя Анонимности.
Объяснение этого в спецификации - "Интерпретация содержимого элемента остается для отдельных реализаций". Что означает, что IdP определяет для него реальный формат, и предполагает, что SP знает, как анализировать данные формата с помощью IdP. Например, IdP предоставляет данные формата "UserName = XXXXX Country = US", SP получает утверждение и может анализировать его и извлекать UserName "XXXXX".