Аутентификация Kerberos

Kerberos используется в корпоративной среде и предназначен для разграничения прав доступа пользователей к различным службам (например, разработчики не должны иметь доступ к бухгалтерским данным). Администраторы создают области Kerberos, охватывающие все ресурсы, к которым возможен доступ. Область определяет, кто и к чему может получить доступ.

Особенности Kerberos:

• имеет особый протокол аутентификации;
• использует билеты (tickets) для аутентификации;
• позволяет не хранить пароли локально и не отправлять их через интернет;
• предполагает участие доверенной третьей стороны;
• основан на криптографии с симметричным ключом.

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

В Kerberos взаимодействуют три стороны:

• сервер аутентификации;
• сервер выдачи билетов;
• служба HTTP, к которой пользователь хочет получить доступ.

Для входа в режим аутентификации сайт должен вернуть код 401 Unauthorized с дополнительным заголовком WWW-Authenticate в ответе.

HTTP/1.1 200 Success
WWW-Authenticate: Negotiate ade0234568a4209af8bc0280289eca

Как происходит обмен данными при доступе к сервису

Клиент и сервер аутентификации

1. Для доступа к сервису клиент представляется серверу аутентификации. После входа в систему с компьютера пользователя к серверу аутентификации посылается запрос в виде обычного текста на получение билета для выдачи билета (TGT — Ticket-Granting Ticket). Текстовое сообщение содержит:

   • имя/идентификатор пользователя;
   • имя/идентификатор запрашиваемой службы (в этом случае служба — это сервер выдачи билетов);
   • сетевой адрес клиента (может быть списком IP-адресов для нескольких компьютеров или быть пустым, чтобы использоваться на любом компьютере);
   • запрашиваемый срок действия TGT.

2. Сервер аутентификации проверяет, существует ли пользователь в базе данных KDC (Key Distribution Center — Центр Распространения Ключей), учетные данные при этом не проверяются. Затем сервер аутентификации отправляет клиенту два сообщения:

   1. Сообщение TGT, зашифрованное секретным ключом TGS. Сообщение содержит:

      • имя/идентификатор пользователя;
      • имя/идентификатор TGS;
      • временную метку;
      • сетевой адрес клиента (может быть списком IP-адресов для нескольких компьютеров или быть пустым, чтобы использоваться на любом компьютере);
      • срок действия TGT (может быть таким, как запрошен изначально, или меньшим, если срок действия секретных ключей пользователя или ключей TGS подходит к концу, или другим, установленным при настройке Kerberos);
      • ключ сеанса TGS.

   2. Сообщение, зашифрованное секретным ключом клиента. Сообщение содержит:

      • название/идентификатор TGS;
      • временную метку;
      • срок действия (такой же, как в первом сообщении);
      • ключ сеанса TGS.

   Секретный ключ клиента определяется путем запроса пароля, добавления соли (состоящей из user@REALMNAME.COM) и хеширования всей информации.

Клиент и сервер выдачи билетов

1. Клиент готовит аутентификатор, который содержит:

   • имя/идентификатор пользователя;
   • временную метку.

   Затем клиент зашифровывает этот аутентификатор ключом TGS.

2. Клиент отправляет серверу выдачи билетов незашифрованное сообщение, которое содержит:

   • имя/идентификатор сервиса, к которому требуется получить доступ;
   • срок действия билета;
   • полученный перед этим аутентификатор;
   • полученное от сервера аутентификации сообщение TGT.

3. Сервер выдачи билетов проверяет базу данных KDC, чтобы узнать, существует ли служба HTTP. Если сервис существует, то сервер выдачи билетов расшифровывает TGT с помощью своего секретного ключа. Взяв из расшифрованного TGT ключ сеанса TGS, сервер расшифровывает аутентификатор пользователя.

4. После этого сервер выдачи билетов:

   • сравнивает полученный из аутентификатора идентификатор пользователя с идентификатором TGT;
   • сравнивает временную метку, полученную из аутентификатора, с меткой времени, полученной из TGT;
   • проверяет по временной метке, не истек ли срок действия TGT;
   • убеждается, что средство проверки подлинности еще не находится в кеше TGS (чтобы избежать повторных атак);
   • сравнивает IP-адрес источника с сетевым адресом клиента (если сетевой адрес в исходном запросе не равен null).

5. Если все данные верны, сервер выдачи билетов случайным образом генерирует ключ сеанса службы HTTP и подготавливает для пользователя билет службы HTTP, который содержит:

   • имя/идентификатор пользователя;
   • название/идентификатор службы HTTP;
   • сетевой адрес клиента (может быть списком IP-адресов для нескольких компьютеров или быть пустым, чтобы использоваться на любом компьютере);
   • временную метку;
   • срок действия билета;
   • ключ сеанса службы HTTP.

   После чего шифрует билет с помощью секретного ключа службы HTTP.

6. Сервер выдачи билетов отправляет клиенту два сообщения:

   1. Зашифрованный билет службы HTTP.
   2. Сообщение, зашифрованное ключом сеанса TGS, которое содержит:
      • название/идентификатор службы HTTP;
      • временную метку;
      • срок действия билета;
      • ключ сеанса HTTP.

7. Компьютер пользователя расшифровывает последнее сообщение ключом сеанса TGS, который он ранее кешировал для получения ключа сеанса службы HTTP.

   Билет службы HTTP компьютер пользователя расшифровать не может, поскольку он зашифрован с помощью секретного ключа службы HTTP.

Клиент и служба HTTP

1. Для получения доступа к службе HTTP клиент готовит еще одно сообщение для аутентификации, которое содержит:

   • имя/идентификатор пользователя;
   • временную метку.

   Затем клиент зашифровывает этот аутентификатор ключом сеанса HTTP.

2. Клиент отправляет сервису аутентификатор и билет службы НТТР, полученный ранее от сервера выдачи билетов.

3. Служба HTTP расшифровывает билет с помощью секретного ключа, чтобы получить ключ сеанса HTTP. Затем он использует этот ключ сеанса для расшифровки отправленного клиентом сообщения аутентификатора.

4. Затем служба HTTP:

   • сравнивает полученный из аутентификатора идентификатор пользователя с идентификатором TGT;
   • сравнивает временную метку, полученную из аутентификатора, с меткой времени, полученной из TGT;
   • проверяет по временной метке, не истек ли срок действия TGT;
   • убеждается, что средство проверки подлинности еще не находится в кеше TGS (чтобы избежать повторных атак);
   • сравнивает IP-адрес источника с сетевым адресом клиента (если сетевой адрес в исходном запросе не равен null).

5. Затем служба HTTP отправляет клиенту сообщение аутентификатора, содержащее его идентификатор и временную метку, чтобы подтвердить свою подлинность. Сообщение зашифровано с помощью ключа сеанса службы HTTP.

6. Компьютер пользователя считывает сообщение аутентификатора, расшифровывая его с помощью кешированного сеансового ключа службы HTTP, и знает, что он должен получить сообщение с идентификатором службы HTTP и временной меткой.

Аутентификация для использования службы HTTP получена. В будущих запросах используется кешированный запрос службы HTTP, если срок его действия не истек, как определено в атрибуте lifetime.

Полезные ссылки

Промостраница Яндекс Браузера для организаций