SSO с использованием Kerberos в Windows и Linux - PullRequest
Новая
       106

SSO с использованием Kerberos в Windows и Linux

0 голосов
/ 21 декабря 2018

У нас есть клиент-серверное приложение, которое разработано внутри компании.Клиенты и сервер обмениваются данными через TCP / IP-соединение по протоколу конкретного приложения.Клиенты работают на Windows, а сервер работает на Linux.Все машины находятся в одном домене / области Active Directory / Kerberos.

В настоящее время пользователь вводит имя пользователя и пароль при запуске приложения.Сервер проверяет имя пользователя и пароль (аутентификация).На основе имени пользователя сервер также определяет доступ к ресурсам (авторизация).

Мы хотим добавить в приложение возможности единого входа (SSO).То есть мы не хотим, чтобы пользователь вводил имя пользователя и пароль, но мы хотим автоматически войти в систему в качестве текущего пользователя Windows.

Конечно, определение текущего пользователя Windows должно быть выполнено безопасно.

Я предложил следующую настройку:

  1. Я использую SSPI (согласование) в Windows и GSSAPI в Linux.
  2. Когда клиент подключается к серверу, он используетAcquireCredentialsHandle (Negotiate) для получения учетных данных текущего пользователя Windows.
  3. Клиент использует InitializeSecurityContext (Negotiate) для создания токена на основе этих учетных данных.
  4. Клиент отправляет токен на сервер.
  5. Сервер использует gss_acquire_cred() для получения учетных данных службы.Они хранятся в файле .keytab.
  6. Сервер получает токен от клиента.
  7. Сервер использует gss_accept_sec_context() для обработки токена.Этот вызов также возвращает «имя источника», то есть текущего пользователя Windows клиента.
  8. Сервер использует «имя источника» в качестве имени пользователя: сервер не выполняет дополнительную аутентификацию.Сервер все еще выполняет авторизацию.

Это работает, но у меня есть несколько вопросов:

  1. Это безопасно? не должно позволять клиенту указывать любое другое имя пользователя, кроме пользователя Windows клиентского процесса.Если у пользователя есть учетные данные для создания процесса как другого пользователя (легально или нелегально), то это разрешено.
  2. Должен ли я выполнить дополнительные проверки для проверки имени пользователя?
  3. Существуют ли альтернативные способыдобиться SSO в этой настройке?Каковы их плюсы и минусы?

1 Ответ

0 голосов
/ 01 марта 2019

То, что вы описали здесь, является правильным способом аутентификации пользователя.Вам не нужно беспокоиться о том, что пользователь указывает другое имя;это то, что Kerberos заботится о вас.

Если клиент может получить билет службы, он должен был пройти проверку подлинности на KDC (Active Directory).KDC создает билет службы, который включает имя пользователя, и шифрует его с помощью секретного ключа службы.

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

Конечно, все это предполагает, что вы все настроили правильно;например, клиент не должен иметь доступа к файлу keytab службы, а служба не должна иметь никаких принципалов на своей вкладке ключей, кроме своей собственной.

Здесь довольно подробное объяснение того, как это работает здесь .

...