1. Обзор
В этом руководстве мы разберемся с основами протокола аутентификации Kerberos. Мы также рассмотрим потребность в SPNEGO в связи с Kerberos.
Наконец, мы увидим, как использовать расширение Spring Security Kerberos для создания приложений с поддержкой Kerberos с помощью SPNEGO.
Прежде чем мы продолжим, стоит отметить, что в этом руководстве будет представлено много новых терминов для тех, кто не знаком с этой областью. Следовательно, мы потратим некоторое время впереди, чтобы прикрыть территорию.
2. Понимание Kerberos
Kerberos — это протокол сетевой аутентификации, разработанный в Массачусетском технологическом институте (MIT) в начале восьмидесятых годов. Как вы понимаете, это относительно старое и выдержало испытание временем. Windows Server широко поддерживает Kerberos в качестве механизма проверки подлинности и даже сделал его вариантом проверки подлинности по умолчанию.
Технически Kerberos — это протокол аутентификации на основе билетов, который позволяет узлам в компьютерной сети идентифицировать себя друг с другом.
2.1. Простой пример использования Kerberos
Давайте составим гипотетическую ситуацию, чтобы продемонстрировать это.
Предположим, что пользователю с помощью своего почтового клиента на своей машине необходимо получить свои электронные письма с почтового сервера на другой машине в той же сети. Здесь очевидна необходимость аутентификации. Почтовый клиент и почтовый сервер должны иметь возможность идентифицировать друг друга и доверять друг другу, чтобы они могли безопасно обмениваться данными.
Как здесь может помочь Kerberos? Kerberos представляет третью сторону под названием Центр распространения ключей (KDC) , которая имеет взаимное доверие с каждым узлом в сети. Давайте посмотрим, как это может работать в нашем случае:
2.2. Ключевые аспекты протокола Kerberos
Хотя это может показаться эзотерическим, это довольно просто и творчески подходит для защиты связи в незащищенной сети. Некоторые из представленных здесь проблем воспринимаются как должное в эпоху TLS повсеместно!
Хотя подробное обсуждение протокола Kerberos здесь невозможно, давайте рассмотрим некоторые важные аспекты:
- Предполагается, что доверие между узлами (клиентом и сервером) и KDC существует в одной и той же области.
- Пароль никогда не передается по сети
- Доверие между клиентом и сервером подразумевается на основании того факта, что они могут расшифровывать сообщения ключом, общим только для KDC.
- Доверие между клиентом и сервером взаимно
- Клиент может кэшировать билеты для повторного использования до истечения срока действия, обеспечивая единый вход в систему.
- Сообщения аутентификатора основаны на отметке времени и поэтому подходят только для одноразового использования.
- Все три стороны здесь должны иметь относительно синхронизированное время
Хотя это лишь малая часть этого красивого протокола аутентификации, этого достаточно, чтобы начать работу с нашим учебным пособием.
3. Понимание SPNEGO
SPNEGO расшифровывается как Simple and Protected GSS-API Negotiation Mechanism . Довольно имя! Давайте сначала посмотрим, что означает GSS-API. Универсальный программный интерфейс службы безопасности (GSS-API) — это не что иное, как стандарт IETF для клиента и сервера, обеспечивающий безопасное и независимое от поставщика взаимодействие.
SPNEGO является частью GSS-API для клиента и сервера для согласования выбора механизма безопасности для использования, например, Kerberos или NTLM.
4. Зачем нам нужен SPNEGO с Kerberos?
Как мы видели в предыдущем разделе, Kerberos — это чистый протокол сетевой аутентификации, работающий преимущественно на транспортном уровне (TCP/UDP). Хотя это хорошо для многих случаев использования, это не соответствует требованиям современной сети. Если у нас есть приложение, работающее с более высокой абстракцией, например HTTP, напрямую использовать Kerberos невозможно.
Здесь нам на помощь приходит SPNEGO. В случае веб-приложения связь в основном происходит между веб-браузером, таким как Chrome, и веб-сервером, таким как Tomcat, на котором размещается веб-приложение через HTTP. Если включено, они могут согласовывать Kerberos в качестве механизма безопасности через SPNEGO и обмениваться билетами в виде токенов SPNEGO через HTTP .
Итак, как это меняет наш сценарий, упомянутый ранее? Давайте заменим наш простой почтовый клиент веб-браузером, а почтовый сервер — веб-приложением:
Таким образом, по сравнению с нашей предыдущей диаграммой здесь мало что изменилось, за исключением того, что связь между клиентом и сервером теперь происходит явно через HTTP. Давайте лучше разберемся в этом:
- Клиентский компьютер аутентифицируется в KDC и кэширует TGT.
- Веб-браузер на клиентском компьютере настроен на использование SPNEGO и Kerberos.
- Веб-приложение также настроено для поддержки SPNEGO и Kerberos.
- Веб-приложение бросает вызов «Переговоры» веб-браузеру, пытающемуся получить доступ к защищенному ресурсу.
- Сервисный билет упаковывается в токен SPNEGO и передается как HTTP-заголовок.
5. Требования
Прежде чем мы сможем приступить к разработке веб-приложения, поддерживающего режим аутентификации Kerberos, мы должны выполнить некоторые базовые настройки. Давайте быстро пройдемся по этим заданиям.
5.1. Настройка KDC
Настройка среды Kerberos для производственного использования выходит за рамки данного руководства. К сожалению, это нетривиальная задача, к тому же хрупкая. Существует несколько вариантов реализации Kerberos, как с открытым исходным кодом, так и в коммерческих версиях:
- Массачусетский технологический институт делает реализацию Kerberos v5 доступной для нескольких операционных систем .
- Apache Kerby — это расширение Apache Directory, которое обеспечивает привязку Java Kerberos.
- Windows Server от Microsoft поддерживает Kerberos v5, изначально поддерживаемый Active Directory.
- У Heimdel есть реализация Kerberos v5
Фактическая настройка KDC и соответствующей инфраструктуры зависит от провайдера и должна следовать их соответствующей документации. Однако Apache Kerby можно запускать внутри контейнера Docker , что делает его платформо-нейтральным.
5.2. Настройка пользователей в KDC
Нам нужно настроить двух пользователей — или, как они это называют, принципалов — в KDC. Для этой цели мы можем использовать инструмент командной строки «kadmin». Предположим, мы создали область под названием «foreach.com» в базе данных KDC и вошли в «kadmin» с пользователем, имеющим права администратора.
Мы создадим нашего первого пользователя, которого мы хотим аутентифицировать из веб-браузера, с помощью:
$ kadmin: addprinc -randkey kchandrakant -pw password
Principal "kchandrakant@foreach.com" created.
Нам также необходимо зарегистрировать наше веб-приложение в KDC:
$ kadmin: addprinc -randkey HTTP/demo.kerberos.foreach.com@foreach.com -pw password
Principal "HTTP/demo.kerberos.foreach.com@foreach.com" created.
Обратите внимание на принятое здесь соглашение об именовании принципала, так как оно должно соответствовать домену, в котором приложение доступно из веб-браузера. Веб- браузер автоматически пытается создать имя участника-службы (SPN) с этим соглашением при появлении запроса «Согласовать».
Нам также нужно экспортировать это как файл keytab, чтобы сделать его доступным для веб-приложения:
$ kadmin: ktadd -k foreach.keytab HTTP/demo.kerberos.foreach.com@foreach.com
Это должно дать нам файл с именем «foreach.keytab».
5.3. Конфигурация браузера
Нам нужно включить веб-браузер, который мы используем для доступа к защищенному ресурсу в веб-приложении, для схемы аутентификации «Переговоры». К счастью, большинство современных веб-браузеров, таких как Chrome, по умолчанию поддерживают «Переговоры» в качестве схемы аутентификации.
Кроме того, мы можем настроить браузер для обеспечения «встроенной аутентификации». В этом режиме при вызове «Согласовать» браузер пытается использовать кэшированные учетные данные на хост-компьютере, который уже зарегистрирован в системе KDC. Однако мы не будем использовать этот режим здесь, чтобы все было ясно.
5.4. Конфигурация домена
Понятно, что у нас может не быть реальных доменов для тестирования нашего веб-приложения. Но, к сожалению, мы не можем использовать localhost или 127.0.0.1 или любой другой IP-адрес с аутентификацией Kerberos. Однако для этого есть простое решение, которое включает в себя настройку записей в файле «hosts», например:
demo.kerberos.bealdung.com 127.0.0.1
6. Весна к нам на помощь!
Наконец, поскольку мы прояснили основы, пришло время проверить теорию. Но не будет ли сложно создать веб-приложение, поддерживающее SPNEGO и Kerberos? Нет, если мы используем Spring. Spring имеет расширение Kerberos как часть Spring Security, которое беспрепятственно поддерживает SPNEGO с Kerberos.
Почти все, что нам нужно сделать, это просто настроить Spring Security, чтобы включить SPNEGO с Kerberos. Здесь мы будем использовать конфигурации в стиле Java, но конфигурацию XML можно настроить так же легко. Мы можем расширить класс WebSecurityConfigurerAdapter , чтобы настроить все, что нам нужно.
6.1. Зависимости Maven
Первое, что нам нужно настроить, это зависимости:
<dependency>
<groupId>org.springframework.security.kerberos</groupId>
<artifactId>spring-security-kerberos-web</artifactId>
<version>${kerberos.extension.version}</version>
</dependency>
<dependency>
<groupId>org.springframework.security.kerberos</groupId>
<artifactId>spring-security-kerberos-client</artifactId>
<version>${kerberos.extension.version}</version>
</dependency>
Эти зависимости доступны для загрузки с Maven Central .
6.2. Конфигурации СПНЕГО
Во-первых, SPNEGO интегрирован в Spring Security как фильтр в HTTPSecurity :
@Override
protected void configure(HttpSecurity http) throws Exception {
http.authorizeRequests()
.anyRequest()
.authenticated()
.and()
.addFilterBefore(
spnegoAuthenticationProcessingFilter(authenticationManagerBean()),
BasicAuthenticationFilter.class);
}
Это показывает только часть, необходимую для настройки фильтра SPNEGO , и не является полной конфигурацией HTTPSecurity , которую следует настроить в соответствии с требованиями безопасности приложения.
Затем нам нужно предоставить фильтр SPNEGO как Bean :
@Bean
public SpnegoAuthenticationProcessingFilter spnegoAuthenticationProcessingFilter(
AuthenticationManager authenticationManager) {
SpnegoAuthenticationProcessingFilter filter = new SpnegoAuthenticationProcessingFilter();
filter.setAuthenticationManager(authenticationManager);
return filter;
}
6.3. Конфигурации Kerberos
Кроме того, мы можем настроить Kerberos, добавив AuthenticationProvider в AuthenticationManagerBuilder в Spring Security:
@Override
protected void configure(AuthenticationManagerBuilder auth) throws Exception {
auth
.authenticationProvider(kerberosAuthenticationProvider())
.authenticationProvider(kerberosServiceAuthenticationProvider());
}
Первое, что мы должны предоставить, это KerberosAuthenticationProvider как Bean . Это реализация AuthenticationProvider , и здесь мы устанавливаем SunJaasKerberosClient как 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 . Это реализация KerberosTicketValidator и использует модуль входа SUN JAAS:
@Bean
public SunJaasKerberosTicketValidator sunJaasKerberosTicketValidator() {
SunJaasKerberosTicketValidator ticketValidator = new SunJaasKerberosTicketValidator();
ticketValidator.setServicePrincipal("HTTP/demo.kerberos.bealdung.com@foreach.com");
ticketValidator.setKeyTabLocation(new FileSystemResource("foreach.keytab"));
return ticketValidator;
}
6.4. Сведения о пользователе
Ранее мы видели ссылки на UserDetailsService в нашем AuthenticationProvider , так зачем нам это нужно? Итак, как мы узнали о Kerberos, это исключительно механизм аутентификации, основанный на билетах.
Таким образом, хотя он может идентифицировать пользователя, он не предоставляет других сведений, связанных с пользователем, таких как его авторизация. Нам нужен действительный UserDetailsService , предоставленный нашему AuthenticationProvider , чтобы заполнить этот пробел.
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 .