Для чего используются разные форматы NameID?

В файле метаданных SAML определено несколько форматов NameID, например:

<NameIDFormat>urn:mace:shibboleth:1.0:nameIdentifier</NameIDFormat>

<NameIDFormat>urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified</NameIDFormat>

<NameIDFormat>urn:oasis:names:tc:SAML:2.0:nameid-format:transient</NameIDFormat>

Кто-нибудь может объяснить, для чего они используются? Каковы различия?


saml single-sign-on opensaml
person performanceuser    schedule 27.07.2012    source источник

Ответы (4)


arrow_upward
68
arrow_downward

См. раздел 8.3 этого основного файла SAML. спецификации oasis SAML.

SP и IdP обычно сообщают друг другу о предмете. Этот субъект должен быть идентифицирован с помощью NAME-IDentifier , который должен быть в некотором формате, чтобы другой стороне было легко идентифицировать его на основе формата.

Все эти

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

являются форматом для идентификаторов имен.

Формат имени временного идентификатора в SAML 1: urn:mace:shibboleth:1.0:nameIdentifier и в SAML 2 это urn:oasis:names:tc:SAML:2.0:nameid-format:transient

Transient предназначен для [раздела 8.3.8 Ядро SAML]

Указывает, что содержимое элемента является идентификатором с переходной семантикой и ДОЛЖНО рассматриваться проверяющей стороной как непрозрачное и временное значение.

Можно использовать Unspecified, и это зависит исключительно от реализации сущностей по их собственному желанию.

person mavis    schedule 10.02.2014
comment
Если вы возвращаете свой идентификатор пользователя, и он общедоступен, и вы не собираетесь менять его в ближайшее время, то я считаю, что вам нужен постоянный. - person Rob Starling; 10.02.2014
comment
Я не вижу в спецификации ничего, что говорит о том, что неуказанный формат следует рассматривать как [по умолчанию]. Мне было бы очень интересно найти ссылку на это. Вы помните, откуда вы это взяли? - person alxgomz; 25.07.2017
comment
@alxgomz — см. строку 455 и далее в спецификация, в частности Unless otherwise specified by an element based on this type, if no Format value is provided, then the value urn:oasis:names:tc:SAML:1.0:nameid-format:unspecified (see Section 8.3.1) is in effect. - person Mike Partridge; 18.01.2018
comment
Transient указывает, что NameID будет чем-то случайным, например, MfJkZue5tTB0mSqfUMe4iPqLd4e. Если тот же человек удалит свои файлы cookie и полностью повторно аутентифицируется, идентификатор изменится. Однако иногда значение по умолчанию является временным и не изменяется, но NameID на самом деле настроен на что-то еще фиксированное, например, адрес электронной почты или имя пользователя. Обратите внимание, что временное имя-идентификатор в ответе saml предполагается использовать только до времени, установленного в NotOnOrAfter в условии субъекта, если оно есть. - person Curtis Yallop; 27.02.2018

arrow_upward
23
arrow_downward

Об этом, я думаю, вы можете сослаться на http://docs.oasis-open.org/security/saml/Post2.0/sstc-saml-tech-overview-2.0.html.

Вот мое понимание этого, а также вариант использования Identity Federation, чтобы дать подробную информацию об этих концепциях:

  • Постоянные идентификаторы-

IdP предоставляет постоянные идентификаторы, они используются для привязки к локальным учетным записям в SP, но каждый из них идентифицируется как профиль пользователя для конкретной службы. Например, постоянные идентификаторы вроде: johnForAir, jonhForCar, johnForHotel, все они только для одной указанной службы, поскольку она должна ссылаться на свою локальную идентификацию в службе.

  • Временные идентификаторы-

Временные идентификаторы — это то, что IdP сообщает SP, что пользователям в сеансе был предоставлен доступ к ресурсу на SP, но идентификаторы пользователей фактически не предлагаются SP. Например, утверждение точно такое же, как «Анонимность (Idp не сообщает SP, кто он такой) имеет разрешение на доступ к / ресурсу на SP». SP получил его и разрешил браузеру получить к нему доступ, но до сих пор не знает настоящего имени Anonymity.

  • неуказанные идентификаторы-

Объяснение этого в спецификации: «Интерпретация содержимого элемента оставлена ​​​​на усмотрение отдельных реализаций». Это означает, что IdP определяет для него реальный формат и предполагает, что SP знает, как анализировать данные формата, полученные от IdP. Например, IdP предоставляет данные формата «UserName=XXXXX Country=US», SP получает утверждение и может анализировать его и извлекать имя пользователя «XXXXX».

person Ron    schedule 12.06.2017
comment
Престижность для моего понимания об этом. Иногда размышления человека, синтезировавшего информацию в спецификации, более ценны, чем сама спецификация. Оцените комментарий. - person chaserb; 16.11.2018

arrow_upward
13
arrow_downward

Это всего лишь подсказка поставщику услуг о том, чего ожидать от NameID, возвращаемого поставщиком удостоверений. Может быть:

  1. unspecified
  2. emailAddress – e.g. [email protected]
  3. X509SubjectName – e.g. CN=john,O=Company Ltd.,C=US
  4. WindowsDomainQualifiedName – e.g. CompanyDomain\John
  5. kerberos– e.g. john@realm
  6. entity — используется для идентификации объектов, предоставляющих услуги на основе SAML, и выглядит как URI.
  7. persistent – это непрозрачный идентификатор службы, который должен включать псевдослучайное значение и не должен быть отслежен до фактического пользователя, поэтому это функция конфиденциальности.
  8. transient – непрозрачный идентификатор, который следует рассматривать как временный.
person kirelagin    schedule 29.07.2018
comment
Когда вы говорите, что это всего лишь подсказка, может ли IDP предоставить что-то помимо того, что было запрошено? И если да, то может ли это все еще работать? - person Matt Shepherd; 04.02.2020
comment
В спецификации об этом ничего нет. - person kirelagin; 05.02.2020

arrow_upward
4
arrow_downward

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:
person Wes    schedule 31.07.2015