Какая польза от пользователя предварительной аутентификации в конфигурации SPNEGO SSO?

Я использую SPNEGO для реализации решения SSO. Во время настройки мне нужно было использовать учетные данные пользователя домена в 2 шага:

  1. В web.xml моего приложения:

     <init-param>
      <param-name>spnego.preauth.username</param-name>
      <param-value>myuser</param-value>
 </init-param>
 <init-param>
      <param-name>spnego.preauth.password</param-name>
      <param-value>mypassword</param-value>
 </init-param>

  2. В команде setspn: setspn -A <mySPN> myuser

Когда я использовал эту конфигурацию, имя пользователя пользователя myuser было получено приложением Java с помощью getRemoteUser(). Так что SSO работал нормально. Но когда я попытался открыть сеанс от имени других пользователей (на том же сервере Windows), он также сработал, поэтому я немного запутался. Это привело меня к таким вопросам:

Почему SSO работал для всех остальных пользователей домена? Должен ли я использовать одного и того же пользователя в командах web.xml и setspn? И какого пользователя выбрать? Каково точное использование имени участника-службы в сценарии Kerberos? Должен ли я выполнять команду setspn на каждом компьютере с Windows или есть способ сделать это только один раз?


single-sign-on kerberos spnego spn
person oabouzaid    schedule 01.04.2021    source источник
comment
Ваш список вопросов на самом деле является одним вопросом. Я сделал это выглядеть также так. Это важно, потому что на сайте не приветствуются списки вопросов. Кроме того, сделайте отступ в своем коде правильно. Я исправил и это.   -  person peterh    schedule 01.04.2021

Ответы (1)


arrow_upward
2
arrow_downward

Эта учетная запись является частью того, что определяет удостоверение сервера в Kerberos.

Kerberos — это протокол с симметричным ключом. У каждого пользователя есть симметричный ключ, который используется совместно пользователем и KDC, и аналогичным образом каждая служба (акцептор) имеет симметричный ключ, который используется совместно службой и KDC.

Когда пользователь запрашивает билеты для определенного субъекта-службы, KDC возвращает их в зашифрованном виде с использованием ключа этой службы. Таким образом, чтобы служба могла расшифровать эти билеты Kerberos, ей также необходимо каким-то образом узнать ключ, связанный с ее собственным субъектом-службой.

Часто служебный ключ генерируется случайным образом и предоставляется через файл keytab. Однако в системах Active Directory большинство учетных записей служб являются обычными учетными записями пользователей, у которых есть пароль, поэтому вместо этого их ключ может быть получен из пароля службы.

Похоже, что ваш модуль SPNEGO поддерживает оба метода (см. строки 150-160) - ему можно указать keytab или пароль.

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

Каково точное использование имени участника-службы в сценарии Kerberos?

Это похоже на поле доменного имени в сертификатах HTTPS. Например, когда браузер выполняет аутентификацию Kerberos для https://example.com, он всегда будет запрашивать билет Kerberos для SPN HTTP/example.com из KDC.

Если вы знакомы с OAuth2, SAML или JWT, я полагаю, что имя участника-службы Kerberos будет грубым эквивалентом поля аудитории в утверждениях SAML или поля aud в JWT.

(Обратите внимание, что браузер только знает вашу службу по ее имени участника-службы и не заботится о фактических учетных записях службы, которые используются за кулисами — например, Active Directory сопоставляет имена участников-служб с реальными учетными записями пользователей в этом случай, но другие реализации Kerberos делают это по-другому)

Должен ли я использовать одного и того же пользователя в командах web.xml и setspn?

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

И какого пользователя выбрать?

Создайте новую специальную учетную запись только для этой службы. Не используйте учетную запись реального человека.

Используйте длинный, очень случайный пароль и пометьте его как бессрочный. Кроме того, убедитесь, что обе учетные записи поддерживают xxx-битные функции Kerberos AES в параметрах учетной записи (при условии, что ваша штука Java SPNEGO поддерживает AES, что должно быть).

Должен ли я выполнять команду setspn на каждом компьютере с Windows или есть способ сделать это только один раз?

Нет, не имеет значения, где вы его выполняете, потому что он редактирует только реальную учетную запись на контроллерах домена и не оставляет никаких следов на локальном компьютере. (В частности, он устанавливает атрибут servicePrincipalName LDAP для предоставленной учетной записи.)

Клиенты узнают вашу службу только по ее имени участника-службы, и им не нужно знать о сопоставлении учетных записей, которое выполняется KDC за кулисами.

person user1686    schedule 09.04.2021
comment
Это был очень полный ответ. Большое спасибо. - person oabouzaid; 12.04.2021