Nano Hash - криптовалюты, майнинг, программирование

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

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

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

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

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

Я придумал следующую схему:

  1. Я использую SSPI (Negotiate) в 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. Есть ли альтернативные способы достижения единого входа в этой настройке? Каковы их плюсы и минусы?
single-sign-on kerberos sspi gssapi
21.12.2018

  • Клиент не должен иметь возможности указать любое другое имя пользователя, кроме текущего пользователя Windows ›Удачи вам с этим. Начнем с того, что текущий пользователь неоднозначен - владелец текущего процесса? Поскольку в ОС Windows может быть запущено несколько сеансов (с законными учетными данными Krb каждый) - несколько сеансов RDP, запланированная задача, выполняющаяся в фоновом режиме для учетной записи службы ... 23.12.2018
  • Kerberos был разработан для безопасной аутентификации в незащищенной сети. Он не защищает от кражи учетных данных на клиентской машине (например, утечки файла keytab). Для защиты от кражи кредитов вам потребуются различные инструменты - например, требовать, чтобы клиентская аутентификация использовала смарт-карту или подобное аппаратное устройство в интерактивном режиме для получения билета Kerberos. 23.12.2018
  • @SamsonScharfrichter Я имею в виду владельца текущего процесса. Если кому-то удается взломать ОС и получить доступ к вещам, к которым он или она не должен иметь доступа, то это проблема, но не то, что мне нужно решать в моем приложении. Мое приложение должно быть устойчивым к действиям, которые может делать любой пользователь, например к изменению переменной среды или использованию взломанного клиентского приложения для отправки настраиваемых созданных сообщений. 24.12.2018
  • Кажется, я реализовал решение, как описано в ответе на этот вопрос., хотя это только для Windows. Это старый вопрос, поэтому сейчас могут быть альтернативы получше. 24.12.2018

Ответы:


1

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

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

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

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

Подробное объяснение того, как это работает, можно найти здесь.

01.03.2019
Новые материалы
Кластеризация: более глубокий взгляд
Кластеризация — это метод обучения без учителя, в котором мы пытаемся найти группы в наборе данных на основе некоторых известных или неизвестных свойств, которые могут существовать. Независимо от..
Как написать эффективное резюме
Предложения по дизайну и макету, чтобы представить себя профессионально Вам не позвонили на собеседование после того, как вы несколько раз подали заявку на работу своей мечты? У вас может..
Частный метод Python: улучшение инкапсуляции и безопасности
Введение Python — универсальный и мощный язык программирования, известный своей простотой и удобством использования. Одной из ключевых особенностей, отличающих Python от других языков, является..
Как я автоматизирую тестирование с помощью Jest
Шутка для победы, когда дело касается автоматизации тестирования Одной очень важной частью разработки программного обеспечения является автоматизация тестирования, поскольку она создает..
Работа с векторными символическими архитектурами, часть 4 (искусственный интеллект)
Hyperseed: неконтролируемое обучение с векторными символическими архитектурами (arXiv) Автор: Евгений Осипов , Сачин Кахавала , Диланта Хапутантри , Тимал Кемпития , Дасвин Де Сильва ,..
Понимание расстояния Вассерштейна: мощная метрика в машинном обучении
В обширной области машинного обучения часто возникает необходимость сравнивать и измерять различия между распределениями вероятностей. Традиционные метрики расстояния, такие как евклидово..
Обеспечение масштабируемости LLM: облачный анализ с помощью AWS Fargate и Copilot
В динамичной области искусственного интеллекта все большее распространение получают модели больших языков (LLM). Они жизненно важны для различных приложений, таких как интеллектуальные..