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

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

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

Upon successful authentication a TGT is returned that can be used for any future interaction with any Kerberos service in the system

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

Client asks for something from my server - My server needs access to customer's HDFS, which requires Kerberos auth - Server authenticates without asking the client to authenticate again

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

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

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

A more senior engineer recommended I look into SASL so that we might support several auth protocols simultaneously; standard customers can authenticate their users with the PLAIN method (over TLS), for instance, while other customers could limit authentication to only the GSSAPI method

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

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

There is a big downside to this, though: pretend the customer's Kerberos system has two realms: one with access to HDFS and one without. If users of both reals are allowed to use my system, but only one set can use HDFS, then I will need my own logic (and potentially objects in a DB) to determine who can perform actions that will require access to HDFS and who cannot.

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

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