«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, как с открытым исходным кодом, так и в коммерческих версиях:

    MIT делает реализацию Kerberos v5 доступной для нескольких операционных систем. Apache Kerby — это расширение Apache Directory, которое обеспечивает привязку Java Kerberos к Windows. Сервер от Microsoft поддерживает Kerberos v5, изначально поддерживаемый Active Directory Heimdel имеет реализацию Kerberos v5

Фактическая настройка KDC и соответствующей инфраструктуры зависит от поставщика и должна следовать из их соответствующей документации. Однако Apache Kerby можно запускать внутри контейнера Docker, что делает его платформо-нейтральным.

5.2. Настройка пользователей в KDC

Нам нужно настроить двух пользователей — или, как они это называют, принципалов — в KDC. Для этой цели мы можем использовать инструмент командной строки «kadmin». Предположим, мы создали область под названием «baeldung.com» в базе данных KDC и вошли в «kadmin» с пользователем, имеющим права администратора.

Мы создадим нашего первого пользователя, которого мы хотим аутентифицировать из веб-браузера, с помощью: 

$ kadmin: addprinc -randkey kchandrakant -pw password
Principal "[email protected]" created.

Нам также потребуется зарегистрировать наше веб-приложение в KDC: 


$ kadmin: addprinc -randkey HTTP/[email protected]baeldung.com -pw password
Principal "HTTP/[email protected]" created.

Примечание. соглашение об именовании принципала здесь, так как оно должно соответствовать домену, в котором приложение доступно из веб-браузера. Веб-браузер автоматически пытается создать имя участника-службы (SPN) с этим соглашением при появлении запроса «Согласовать».

Нам также нужно экспортировать это как файл keytab, чтобы сделать его доступным для веб-приложения: 

$ kadmin: ktadd -k baeldung.keytab HTTP/[email protected]

Это должно дать нам файл с именем «baeldung.keytab».

5.3. Конфигурация браузера

Нам нужно включить веб-браузер, который мы используем для доступа к защищенному ресурсу в веб-приложении для схемы аутентификации «Negotiate». К счастью, большинство современных веб-браузеров, таких как 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

Во-первых, 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
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/[email protected]");
    ticketValidator.setKeyTabLocation(new FileSystemResource("baeldung.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.