Автор оригинала: Kumar Chandrakant.
1. Обзор
В этом уроке мы разберемся в основах протокола аутентификации Kerberos. Мы также рассмотрим необходимость SPNEGO в связи с Kerberos.
Наконец, мы увидим, как использовать расширение Spring Security Kerberos для создания приложений, включенных для Kerberos с помощью SPNEGO.
Прежде чем мы продолжим, стоит отметить, что этот учебник введет много новых терминов для тех, кто не посвящен в эту область. Следовательно, мы проведем некоторое время впереди, чтобы осмотреть территорию.
2. Понимание Kerberos
Технически Kerberos-это протокол аутентификации на основе билетов, который позволяет узлам компьютерной сети идентифицировать себя друг с другом.
2.1. Простой вариант использования Kerberos
Давайте нарисуем гипотетическую ситуацию, чтобы продемонстрировать это.
Предположим, что пользователь через свой почтовый клиент на своей машине должен получать свои электронные письма с почтового сервера на другой машине в той же сети. Здесь очевидна необходимость аутентификации. Почтовый клиент и почтовый сервер должны быть способны идентифицировать друг друга и доверять друг другу, чтобы они могли безопасно общаться.
Как Kerberos может помочь нам здесь? Kerberos вводит третью сторону под названием Key Distribution Centre (KDC) , которая имеет взаимное доверие с каждым узлом в сети. Давайте посмотрим, как это может работать в нашем случае:
2.2. Ключевые аспекты протокола Kerberos
Хотя это может показаться эзотерическим, это довольно простой и творческий подход к обеспечению связи по незащищенной сети. Некоторые из представленных здесь проблем вполне воспринимаются как должное в эпоху TLS повсюду!
Хотя подробное обсуждение протокола Kerberos здесь невозможно, давайте рассмотрим некоторые важные аспекты:
- Предполагается, что доверие между узлами (клиентом и сервером) и KDC существует здесь в одной и той же области
- Пароль никогда не обменивается по сети
- Доверие между клиентом и сервером подразумевается на основе того факта, что они могут расшифровывать сообщения с помощью ключа, общего только с KDC
- Доверие между клиентом и сервером взаимно
- Клиент может кэшировать билеты для повторного использования до истечения срока действия, обеспечивая единый вход
- Сообщения аутентификатора основаны на метке времени и поэтому хороши только для одноразового использования
- Все три стороны здесь должны иметь относительно синхронизированное время
Хотя это просто царапает поверхность этого прекрасного протокола аутентификации, этого достаточно, чтобы мы начали наш учебник.
3. Понимание SPNEGO
SPNEGO расшифровывается как Простой и защищенный механизм согласования GSS-API . Ну и имя! Давайте сначала посмотрим, что означает GSS-API. Интерфейс прикладных программ Generic Security Service Application Program Interface (GSS-API)-это не что иное, как стандарт IETF, позволяющий клиенту и серверу взаимодействовать безопасным и независимым от поставщика образом.
SPNEGO является частью GSS-API для клиента и сервера для согласования выбора механизма безопасности для использования, например, Kerberos или NTLM.
4. Зачем Нам Нужен SPNEGO С Kerberos?
Как мы видели в предыдущем разделе, Kerberos-это чистый сетевой протокол аутентификации, работающий в основном на транспортном уровне (TCP/UDP). Хотя это хорошо для многих случаев использования, это не соответствует требованиям современного Интернета. Если у нас есть приложение, которое работает на более высокой абстракции, такой как HTTP, невозможно использовать Kerberos напрямую.
Вот тут-то СПНЕГО и приходит нам на помощь. В случае веб-приложения связь в основном происходит между веб-браузером, таким как Chrome, и веб-сервером, таким как Tomcat, размещающим веб-приложение по протоколу HTTP. Если он включен, они могут согласовывать Kerberos как механизм безопасности через SPNEGO и обмениваться билетами как токенами SPNEGO через HTTP .
Так как же это меняет наш сценарий, упомянутый ранее? Давайте заменим наш простой почтовый клиент веб – браузером, а почтовый сервер-веб – приложением:
Таким образом, в этом мало что изменилось по сравнению с нашей предыдущей диаграммой, за исключением того, что связь между клиентом и сервером теперь происходит явно по протоколу HTTP. Давайте разберемся в этом лучше:
- Клиентская машина аутентифицируется по KDC и кэширует TGT
- Веб-браузер на клиентском компьютере настроен на использование SPNEGO и Kerberos
- Веб-приложение также настроено на поддержку SPNEGO и Kerberos
- Веб-приложение бросает вызов “Договориться” веб-браузеру, пытающемуся получить доступ к защищенному ресурсу
- Сервисный билет упаковывается как токен SPNEGO и обменивается как HTTP заголовок
5. Требования
Прежде чем мы сможем приступить к разработке веб-приложения, поддерживающего режим аутентификации Kerberos, мы должны собрать некоторые базовые настройки. Давайте быстро пройдемся по этим задачам.
5.1. Настройка KDC
Настройка среды Kerberos для производственного использования выходит за рамки данного руководства. Это, к сожалению, не тривиальная задача и к тому же хрупкая. Существует несколько вариантов реализации Kerberos, как с открытым исходным кодом, так и в коммерческих версиях:
- MIT делает реализацию Kerberos v5 доступной для нескольких операционных систем
- Apache Kerby – это расширение каталога Apache, которое обеспечивает привязку Java Kerberos
- Windows Server от Microsoft поддерживает Kerberos v5 изначально поддерживаемый Active Directory
- Heimdal имеет реализацию Kerberos v5
Фактическая настройка KDC и связанной с ней инфраструктуры зависит от поставщика и должна следовать из их соответствующей документации. Однако Apache Kerby может быть запущен внутри контейнера Docker , что делает его нейтральным к платформе.
5.2. Настройка пользователей в KDC
Нам нужно настроить двух пользователей — или, как они это называют, принципалов — в KDC. Для этого мы можем использовать инструмент командной строки “kadmin”. Предположим, мы создали царство под названием “baeldung.com” в базе данных KDC и вошел в систему “admin” с пользователем, имеющим права администратора.
Мы создадим нашего первого пользователя, которого мы хотим аутентифицировать из веб-браузера, с помощью:
$ kadmin: addprinc -randkey kchandrakant -pw password Principal "[email protected]" created.
Нам также нужно будет зарегистрировать ваше веб-приложение в KDC:
$ kadmin: addprinc -randkey HTTP/[email protected] -pw password Principal "HTTP/[email protected]" created.
Обратите внимание на соглашение об именовании принципала здесь, так как оно должно соответствовать домену, в котором приложение доступно из веб-браузера. Веб-браузер автоматически пытается создать имя участника службы (SPN) в соответствии с этим соглашением, когда ему предъявляется задача “Договориться”.
Нам также нужно экспортировать его в виде файла keytab, чтобы сделать его доступным для веб-приложения:
$ kadmin: ktadd -k baeldung.keytab HTTP/[email protected]
Это должно дать нам файл с именем “baeldung.кейтаб”.
5.3. Конфигурация браузера
Нам нужно включить веб-браузер, который мы используем для доступа к защищенному ресурсу в веб-приложении для схемы аутентификации “Negotiate”. К счастью, большинство современных веб-браузеров, таких как Chrome, по умолчанию поддерживают “Переговоры” в качестве схемы аутентификации.
Кроме того, мы можем настроить браузер так, чтобы он обеспечивал “Интегрированную аутентификацию”. В этом режиме при вызове “Negotiate” браузер пытается использовать кэшированные учетные данные на хост-машине, которая уже вошла в систему участника KDC. Однако мы не будем использовать этот режим здесь, чтобы держать вещи явными.
5.4. Конфигурация домена
Понятно, что у нас может не быть реальных доменов для тестирования нашего веб-приложения. Но, к сожалению, мы не можем использовать localhost или 127.0.0.1 или любой другой IP-адрес с аутентификацией Kerberos. Существует, однако, простое решение этой проблемы, которое включает в себя настройку записей в файле “hosts”, таких как:
demo.kerberos.bealdung.com 127.0.0.1
6. Спешите к Нам На Помощь!
Наконец, когда мы получили ясные основы, пришло время проверить теорию. Но не будет ли громоздко создавать веб-приложение, поддерживающее SPNEGO и Kerberos? Нет, если мы используем Весну. Spring имеет расширение Kerberos как часть Spring Security, которое легко поддерживает SPNEGO с Kerberos .
Почти все, что нам нужно сделать, – это просто настроить Spring Security, чтобы включить SPNEGO с Kerberos. Здесь мы будем использовать конфигурации в стиле Java, но конфигурацию XML можно настроить так же легко. Мы можем расширить класс WebSecurityConfigurerAdapter , чтобы настроить все, что нам нужно.
6.1. Зависимости Maven
Первое, что мы должны настроить, – это зависимости:
org.springframework.security.kerberos spring-security-kerberos-web ${kerberos.extension.version} org.springframework.security.kerberos spring-security-kerberos-client ${kerberos.extension.version}
Эти зависимости доступны для загрузки из Maven Central .
6.2. Конфигурации SPNEGO
Во-первых, SPNEGO интегрирован в Spring Security как Filter in HTTP Security :
@Override
protected void configure(HttpSecurity http) throws Exception {
http.authorizeRequests()
.anyRequest()
.authenticated()
.and()
.addFilterBefore(
spnegoAuthenticationProcessingFilter(authenticationManagerBean()),
BasicAuthenticationFilter.class);
}Это показывает только часть, необходимую для настройки SPNEGO Filter , и не является полной конфигурацией HTTP Security , которая должна быть настроена в соответствии с требованиями безопасности приложения.
Далее нам нужно предоставить SPNEGO Filter as Bean :
@Bean
public SpnegoAuthenticationProcessingFilter spnegoAuthenticationProcessingFilter(
AuthenticationManager authenticationManager) {
SpnegoAuthenticationProcessingFilter filter = new SpnegoAuthenticationProcessingFilter();
filter.setAuthenticationManager(authenticationManager);
return filter;
}6.3. Конфигурации Kerberos
Кроме того, мы можем настроить Kerberos, добавив Authentication Provider в AuthenticationManagerBuilder в Spring Security:
@Override
protected void configure(AuthenticationManagerBuilder auth) throws Exception {
auth
.authenticationProvider(kerberosAuthenticationProvider())
.authenticationProvider(kerberosServiceAuthenticationProvider());
}Первое, что мы должны предоставить, – это поставщик аутентификации Kerberos в качестве Bean . Это реализация Authentication Provider , и именно здесь мы устанавливаем Sun Jaas Kerberos Client как KerberosClient :
@Bean
public KerberosAuthenticationProvider kerberosAuthenticationProvider() {
KerberosAuthenticationProvider provider = new KerberosAuthenticationProvider();
SunJaasKerberosClient client = new SunJaasKerberosClient();
provider.setKerberosClient(client);
provider.setUserDetailsService(userDetailsService());
return provider;
}Далее мы также должны предоставить KerberosServiceAuthenticationProvider в качестве Bean . Это класс, который проверяет Служебные билеты Kerberos или токены SPNEGO:
@Bean
public KerberosServiceAuthenticationProvider kerberosServiceAuthenticationProvider() {
KerberosServiceAuthenticationProvider provider = new KerberosServiceAuthenticationProvider();
provider.setTicketValidator(sunJaasKerberosTicketValidator());
provider.setUserDetailsService(userDetailsService());
return provider;
}Наконец, нам нужно предоставить SunJaasKerberosTicketValidator в качестве Bean . Это реализация Kerberos Ticket Validator и использует модуль входа SUN JAAS:
@Bean
public SunJaasKerberosTicketValidator sunJaasKerberosTicketValidator() {
SunJaasKerberosTicketValidator ticketValidator = new SunJaasKerberosTicketValidator();
ticketValidator.setServicePrincipal("HTTP/[email protected]");
ticketValidator.setKeyTabLocation(new FileSystemResource("baeldung.keytab"));
return ticketValidator;
}6.4. Сведения о пользователе
Мы уже видели ссылки на UserDetailsService в нашем провайдере аутентификации ранее, так зачем же он нам нужен? Ну, как мы уже знаем, Kerberos-это чисто механизм аутентификации, основанный на билетах.
Таким образом, хотя он способен идентифицировать пользователя, он не предоставляет других деталей, связанных с пользователем, таких как его авторизация. Нам нужен действительный UserDetailsService , предоставленный нашему поставщику аутентификации , чтобы заполнить этот пробел.
6.5. Запуск приложения
Это в значительной степени то, что нам нужно, чтобы настроить веб-приложение с включенной Spring Security для SPNEGO с Kerberos. Когда мы загружаем веб-приложение и получаем доступ к любой странице в нем, веб-браузер должен запросить имя пользователя и пароль, подготовить токен SPNEGO с билетом службы и отправить его приложению.
Приложение должно быть в состоянии обработать его, используя учетные данные в файле keytab, и ответить успешной аутентификацией.
Однако, как мы видели ранее, настройка рабочей среды Kerberos сложна и довольно хрупка. Если все идет не так, как ожидалось, стоит еще раз проверить все шаги. Простая ошибка, такая как несоответствие в доменном имени, может привести к сбою с сообщениями об ошибках, которые не особенно полезны.
7. Практическое использование SPNEGO и Kerberos
Теперь, когда мы увидели, как работает аутентификация Kerberos и как мы можем использовать SPNEGO с Kerberos в веб-приложениях, мы можем усомниться в необходимости этого. Хотя это имеет полный смысл использовать его в качестве механизма единого входа в корпоративной сети, почему мы должны использовать его в веб-приложениях?
Ну, во-первых, даже спустя столько лет Kerberos все еще очень активно используется в корпоративных приложениях, особенно в приложениях на базе Windows. Если организация имеет несколько внутренних и внешних веб-приложений, имеет смысл расширить одну и ту же инфраструктуру единого входа, чтобы охватить их все . Это значительно облегчает администраторам и пользователям организации беспрепятственный доступ к различным приложениям.
8. Заключение
Подводя итог, в этом уроке мы поняли основы протокола аутентификации Kerberos. Мы также обсудили SPNEGO как часть GSS-API и то, как мы можем использовать его для облегчения проверки подлинности на основе Kerberos в веб-приложении по протоколу HTTP. Кроме того, мы попытались создать небольшое веб-приложение, используя встроенную поддержку Spring Security для SPNEGO с Kerberos.
Этот учебник просто дает быстрый быстрый взгляд на мощный и проверенный временем механизм аутентификации. Существует довольно много информации, доступной для нас, чтобы узнать больше и, возможно, оценить еще больше!
Как всегда, код можно найти на GitHub .