Основные понятия и аутентификационные протоколы

Пойду-ка домой. Если я — это я,

Меня не укусит собака моя!

Она меня встретит, визжа, у ворот,

А если не я, на куски разорвёт!»

В окно постучала старушка чуть свет.

Залаяла громко собака в ответ.

Старушка присела, сама не своя,

И тихо сказала: «Ну, значит, не я!»

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

Как различить идентификацию, аутентификацию и авторизацию

Аутентификационные протоколы и стандарты

Использование SSO

Применение протокола SAML

Важные части в XML-документе SAML

• Описание типа протокола, типа утверждения, даты выпуска, данных о том, куда переслали пользователя, ID запроса:
  Скопировать код

  XML

  <samlp:Response xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol" xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion" ID="_8e8dc5f69a98cc4c1ff3427e5ce34606fd672f91e6" Version="2.0" IssueInstant="2014-07-17T01:01:48Z" Destination="http://sp.example.com/demo1/index.php?acs" InResponseTo="ONELOGIN_4fee3b046395c4e751011e97f8900b5273d56685"> 
• Информация о том, что утверждение прошло успешно:
  Скопировать код

  XML

  <samlp:StatusCode Value="urn:oasis:names:tc:SAML:2.0:status:Success"/> -  
• Тело утверждения — основная часть документа, содержащая данные о пользователе и их правах. Указывается ID (уникальный идентификатор) для этого утверждения, чтобы его можно было отследить или использовать для последующей проверки:
  Скопировать код

  XML

  <saml:Assertion xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xs="http://www.w3.org/2001/XMLSchema" ID="pfx87ce871b-f7ad-e6e0-e81c-d8d6bc352a57" Version="2.0" IssueInstant="2014-07-17T01:01:48Z"> 
• Подпись — здесь указывается алгоритм цифровой подписи, используемый для защиты документа от подделки:
  Скопировать код

  XML

  <ds:SignatureMethod Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1"/> 
• Данные по субъекту указывают, для кого предназначен документ (например, имя пользователя или ID):
  Скопировать код

  XML

      </saml:Subject>
        <saml:NameID SPNameQualifier="http://sp.example.com/demo1/metadata.php" Format="urn:oasis:names:tc:SAML:2.0:nameid-format:transient">_ce3d2948b4cf20146dee0a0b3dd6f69b6cf86f62d7</saml:NameID> 
• Подтверждение от аутентификационного сервера, на основании которого будет выдаваться токен:
  Скопировать код

  XML

      <saml:AttributeStatement>
        <saml:Attribute Name="uid" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:basic">
          <saml:AttributeValue xsi:type="xs:string">test</saml:AttributeValue> 
  Идентификатор пользователя: test
  Email: test@example.com
  Роли: users, examplerole1

Процесс аутентификации с использованием протокола SAML

1. Неизвестный клиент запрашивает доступ к провайдеру ресурса.
2. Если такой запрос не может быть предоставлен клиенту без аутентификации, провайдер перенаправляет клиента на провайдера идентификаций — Identity Provider.
3. Identity Provider идентифицирует и аутентифицирует пользователя.
4. На основании аутентификационных данных, которые предоставил пользователь, он генерирует документ — XML-assertion (XML-утверждение) — и отдаёт его клиенту в формате SAML. В этом документе указываются те утверждения, которые получилось проверить в отношении тех параметров, которые ожидает ресурс. Например, ресурсу, чтобы аутентифицировать пользователя, надо получить от сервера аутентификации email и уникальный ID. В SAML указывается значение того, что удалось подтвердить.
5. Клиент берёт XML и идёт с ним к ресурсу.
6. Ресурс читает XML, проверяет, что ему можно доверять (каждый XML подписан), аутентифицирует клиента и выдаёт свой access_token.
7. Клиент сохраняет access_token и использует его для работы с этим ресурсом.

Особенности использования SAML-аутентификации

• Java: OneLogin или, если используется Spring, — Spring Security SAML;
• Python: python3-saml для простых случаев, PySAML2 — для сложных;
• Node.js: passport-saml;
• Ruby: ruby-saml;
• Go: crewjam/saml.

• SAML разработан только для аутентификации, что полезно для работы с legacy-системами.
• Протокол SAML широко распространён — больше, чем OpenID Connect.
• Имеет гибкое распространение атрибутов.
• Этот протокол может поддерживать user federation — с его помощью можно подключать разные IDp к аутентификационному серверу.
• Есть документация и отработанные практики безопасности.

• SAML сделан только для веб-приложений и не подходит для нативных (мобильных, десктопных).
• Документ XML имеет большую и сложную для чтения структуру — в качестве альтернативы можно использовать более короткие стандарты, например JWT, о котором расскажем далее.

OpenID Connect

Процесс аутентификации с использованием протокола OpenID Connect

1. Клиент обращается к ресурсу.
2. Ресурс понимает, что клиент не прошёл аутентификацию, и пересылает его на IdP. Пользователь через клиент предоставляет свои креды.
3. Клиенту возвращают id_token, в котором зашифрована информация о пользователе, — примерно как в SAML — список утверждений. Это часть аутентификации. Ещё часто возвращают access_token, но это уже часть авторизации — о ней речь пойдёт дальше в курсе.
4. Ресурс может сделать REST-запрос в аутентификационный сервис за дополнительной информацией о пользователе с использованием выданного токена либо временного кода.
5. Клиент использует токен для аутентифицированных запросов.

Особенности использования аутентификации по OpenID Connect

• OpenID Connect использует удобный и гибкий формат представления данных — JWT. Он позволяет делать дополнительные запросы на REST и получать больше информации. SAML, например, ограничен данными, которые передаются в XML, и для получения дополнительной информации требуется дополнительная настройка.
• Протокол OpenID Connect предоставляет большую гибкость — не только аутентификационную информацию, но и авторизационную.
• Может использоваться в разных типах приложений — не только веб, но и нативных.
• Проще в реализации, чем SAML.
• Встроенная поддержка сессий — можно использовать для них токен.
• Развитая экосистема — множество готовых реализаций, высокая поддержка в облачных сервисах.

• Cвязан с протоколом авторизации OAuth2.0 — если применяется OpenID Connect, то должен применяться OAuth 2.0.
• Риски при неправильном хранении токенов.

Применение протокола Kerberos

Процесс аутентификации с использованием протокола Kerberos

1. Пользователь вводит свои учётные данные (логин и пароль), и Kerberos аутентифицирует его через центральный сервер (Key Distribution Center, KDC).
2. KDC проверяет учётные данные клиента и, если они верны, генерирует два билета:
   • Билет предоставления (Ticket Granting Ticket, TGT) — билет, который позволяет клиенту в дальнейшем получать доступ к другим сервисам без повторной аутентификации.
   • Сессионный ключ — секретный ключ, используемый для шифрования сообщений между клиентом и сервером.
3. Когда пользователь хочет получить доступ к какому-либо сервису, он использует TGT для запроса сервисного билета. KDC проверяет TGT и, если он действителен, генерирует новый билет — сервисный. Он уже позволяет пользователю аутентифицироваться и взаимодействовать с нужным сервисом.
4. Когда срок действия TGT истекает, клиент должен повторно пройти процесс аутентификации, чтобы получить новый TGT.

Особенности использования аутентификации по Kerberos

• Kerberos использует криптографию для защиты передаваемых данных, что снижает риск перехвата и подделки учётных данных.
• Отсутствие необходимости передавать пароли по сети повышает безопасность.
• Kerberos-сервер (KDC) выступает в качестве централизованного пункта аутентификации, упрощая администрирование.
• Администраторы могут легко контролировать доступ к ресурсам и управлять им.
• Kerberos хорошо масштабируется, позволяя обслуживать большое количество клиентов и серверов.
• Kerberos поддерживается различными операционными системами и приложениями. Например, в Active Directory в Microsoft.

• Развёртывание и настройка Kerberos-инфраструктуры может быть трудоёмкой задачей, особенно в больших организациях.
• Kerberos-сервер (KDC) является критически важным компонентом, и его отказ может привести к нарушению работы всей системы.
• Kerberos требует синхронизации времени между клиентами и серверами, что может быть проблематично в распределённых средах.
• Kerberos не всегда хорошо интегрируется с мобильными устройствами, что может затруднять их использование в корпоративной среде.
• Интеграция Kerberos с другими системами аутентификации, такими как LDAP или Active Directory, может быть сложной задачей.

• SAML подходит для организаций с большими корпоративными приложениями и сложными схемами доверия, часто используется для интеграции с облачными сервисами.
• OpenID Connect идеален для современных веб- и мобильных приложений, обеспечивает гибкую аутентификацию и хорошую интеграцию с OAuth 2.0.
• Kerberos лучше всего подходит для локальных сетей и корпоративной среды, где необходимо управление доступом с высоким уровнем безопасности и с использованием билетов.

Что почитать про протоколы аутентификации

• Примеры SAML-протоколов
• Clowdflare — один из провайдеров, предоставляющих SAML-аутентификацию.
• Видео с техническим обзором реализации SAML 2.0
• Описание флоу работы SAML
• Технологический обзор возможностей SAML от комьюнити, которое его использует
• Cпецификации по SAML

• Официальная документация протокола OpenID Connect

• Kerberos простыми словами на Хабре

• Официальный сайт технологии WebAuthn
• Web Authentication API — документация, поддерживаемая сообществом Mozilla
• Beyond Passwords: How WebAuthn Actually Works — видео с описанием работы WebAuthn

Итоги

• Single Sign-On (SSO) — это механизм, позволяющий пользователям аутентифицироваться один раз и получать доступ ко многим приложениям без повторного ввода учётных данных. Это повышает удобство и безопасность. Для реализации SSO используются различные протоколы аутентификации, включая SAML, OpenID Connect и Kerberos.
• SAML (Security Assertion Markup Language) — один из протоколов аутентификации. При входе пользователя запрос аутентификации отправляется на IdP (Identity Provider), который проверяет учётные данные и возвращает XML-утверждение (assertion) об аутентификации. Пользователь получает доступ к запрашиваемому ресурсу, используя это утверждение для подтверждения своей личности.
• OpenID Connect — это протокол, основанный на OAuth 2.0. Когда пользователь пытается войти в систему, его личность проверяется на внешнем сервере авторизации. Этот сервер осуществляет аутентификацию, и затем пользователю возвращается токен доступа и идентификационный токен, содержащий информацию о пользователе. Эти токены используются для авторизации и доступа к ресурсам приложения.
• Kerberos использует систему билетов для аутентификации пользователей в сетях. При входе пользователь получает билет на аутентификацию от KDC (Key Distribution Center). Этот билет позволяет пользователю получить доступ к сервисам без повторного ввода пароля. Kerberos обеспечивает безопасность с помощью симметричного шифрования и временных меток, что делает его подходящим для корпоративных сетей.