Kerberos через SASL: мне нужно получить билет?

Question

Я разрабатываю систему аутентификации для части программного обеспечения, и мне нужно несколько советов о том, как взаимодействуют сервисы SASL и Kerberos.

Вот ситуация:

У меня есть клиент-серверное приложение, которое само по себе довольно стандартно: выполнять действия могут только зарегистрированные пользователи. Как MVP я бы обычно реализовывал довольно стандартное решение:

• База данных хранит имя пользователя + соленый хеш-пароль
• Попытка аутентификации от клиента по HTTP включает имя пользователя / пароль по TLS
• Бэкэнд проверяет правильность имени пользователя и пароля и возвращает токен на предъявителя, который можно использовать на время сеанса

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

Более старший инженер рекомендовал мне изучить SASL, чтобы мы могли поддерживать несколько протоколов аутентификации одновременно; например, обычные клиенты могут аутентифицировать своих пользователей с помощью метода PLAIN (через TLS), тогда как другие клиенты могут ограничить аутентификацию только методом GSSAPI.

До этого момента у меня было четкое представление о том, как можно настроить вещи для достижения желаемых целей. Тем не менее, есть еще один осложняющий фактор. Некоторые клиенты, которые хотят, чтобы аутентификация нашей системы поддерживала Kerberos, имеют другие ресурсы, на которые будет опираться наша система (например, HDFS), которые также требуют аутентификации с помощью Kerberos.

Мое понимание Kerberos таково:

• Клиент аутентифицируется на сервере выдачи билетов Kerberos
• После успешной аутентификации возвращается TGT, который можно использовать для любого будущего взаимодействия с любым сервисом Kerberos в системе

Теперь к вопросу: как я могу заставить все эти технологии работать в гармонии? Что я хочу это: - Клиент заходит на мой сервер - Мой сервер аутентифицирует клиента, используя систему Kerberos клиента - Клиент получает ОК - Клиент просит что-то с моего сервера - Моему серверу нужен доступ к HDFS клиента, который требует аутентификации Kerberos - Сервер аутентифицируется, не запрашивая у клиента повторную аутентификацию

Одним из возможных решений, которое я вижу, является следующее:

• Сделать мой сервер пользователем Kerberos
• Когда серверу необходимо выполнить действие с HDFS, аутентифицируйте его, используя свои собственные учетные данные

Однако в этом есть большой недостаток: представьте, что система Kerberos клиента имеет две области: одну с доступом к HDFS, а другую - без. Если пользователям обоих реалов разрешено использовать мою систему, но только один набор может использовать HDFS, тогда мне понадобится моя собственная логика (и, возможно, объекты в БД), чтобы определить, кто может выполнять действия, для которых потребуется доступ к HDFS, а кто нет. .

Любые указатели будут очень полезными; если это не очевидно, я новичок во всем этом.

Заранее спасибо!

Answer 1

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

Во-первых, я просто хочу прояснить это:

После успешной аутентификации возвращается TGT, который можно использовать для любого будущего взаимодействия с любым сервисом Kerberos в системе

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

Клиент запрашивает что-то с моего сервера - Моему серверу необходим доступ к HDFS клиента, для чего требуется аутентификация Kerberos - Сервер аутентифицируется без запроса повторной аутентификации клиента

Этодостаточно распространенная проблема, и решение Kerberos называется Delegation .Вы должны попытаться использовать делегирование Kerberos вместо того, чтобы придумать собственное решение.Тем не менее, насколько хорошо он поддерживается, зависит от используемого вами технологического стека.

Существует два вида делегирования, поддерживаемых Kerberos.Первый вид называется просто «делегирование», и он работает, отправляя TGT пользователя в сервис вместе с сервисным билетом.Затем служба может использовать TGT для получения новых служебных билетов от KDC от имени пользователя.Недостаток этого подхода заключается в том, что как только служба получает TGT пользователя, она может эффективно олицетворять этого пользователя в любой службе, к которой у него будет доступ.Возможно, вы не захотите, чтобы сервис имел такой уровень свободы.

Второй тип делегирования называется ограниченное делегирование (также известное как services4user или S4U).При таком подходе клиент не отправляет свой TGT в службу, но службе разрешено запрашивать у KDC билет службы, чтобы выдать себя за пользователя в любом случае.Службы, которые могут сделать это, должны быть внесены в белый список на KDC, а также службы, на которые они могут запросить билеты.В конечном итоге это обеспечивает более безопасный подход, поскольку служба не может выдать себя за этого пользователя только за любую службу.

Более старший инженер рекомендовал мне изучить SASL, чтобы мы могли поддерживать несколько протоколов аутентификации одновременно;например, обычные клиенты могут аутентифицировать своих пользователей методом PLAIN (через TLS), в то время как другие клиенты могут ограничить аутентификацию только методом GSSAPI

Да, это хорошая идея.В частности, я бы рекомендовал использовать один и тот же механизм аутентификации сеанса для всех пользователей.Единственная разница для пользователей Kerberos должна заключаться в том, каким образом они получают сеанс.Вы можете настроить защищенный от Kerberos URL-адрес для входа, чтобы они получали сеанс, не запрашивая учетные данные.Любой пользователь, который переходит по этому URL-адресу и не имеет учетных данных Kerberos, может быть просто перенаправлен на страницу входа, которая в конечном итоге получает тот же объект сеанса (после входа в систему).

На серверном уровне логика проверки учетных данных может использовать SASL для передачи пользователей Kerberos через KDC, а другие через локальный механизм аутентификации.Это дает вам беспроблемный резервный механизм для ситуаций, когда Kerberos не работает для пользователей Kerberos (что может произойти достаточно легко из-за таких вещей, как перекос часов и т. Д.)

Есть большой недостаток в этомТем не менее: представьте, что система Kerberos клиента имеет две области: одну с доступом к HDFS и одну без.Если пользователям обоих реалов разрешено использовать мою систему, но только один набор может использовать HDFS, тогда мне понадобится моя собственная логика (и, возможно, объекты в БД), чтобы определить, кто может выполнять действия, для которых потребуется доступ к HDFS, а кто нет..

Подобные вещи и являются причиной того, что вы должны использовать делегирование Kerberos вместо того, чтобы придумывать собственное решение. С делегированием Kerberos администратор KDC контролирует, кто к чему имеет доступ. Если ваша служба пытается выдать себя за пользователя за HDFS, и ему не разрешен доступ к нему, этот шаг аутентификации просто не будет выполнен, и все будет хорошо.

Если вы попытаетесь скрыть правила авторизации KDC в своем собственном приложении, рано или поздно они выйдут из синхронизации и произойдут плохие вещи.