Для чего используется другой формат 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>

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

Источник

4 ответа

Решение

Обратитесь к Разделу 8.3 этого базового PDF SAML спецификации 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

Переходный процесс для [раздел 8.3.8 из SAML Core]

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

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

Источник

Об этом, я думаю, вы можете сослаться на 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".

Источник

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

  1. unspecified
  2. emailAddress - например john@company.com
  3. X509SubjectName - например CN=john,O=Company Ltd.,C=US
  4. WindowsDomainQualifiedName - например CompanyDomain\John
  5. kerberos- например john@realm
  6. entity - этот используется для идентификации объектов, которые предоставляют услуги на основе SAML, и выглядит как URI
  7. persistent - это непрозрачный специфичный для службы идентификатор, который должен включать псевдослучайное значение и не должен отслеживаться фактическим пользователем, поэтому это функция конфиденциальности.
  8. transient - непрозрачный идентификатор, который следует рассматривать как временный.
Источник

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:
Источник
Другие вопросы по тегам