ps
/
docs
4
0
Fork 0
Code Issues Pull Requests Projects Releases Wiki Activity

Дабавлены пробелы, изменены заголовки

pull/1/head
Арина Ашотян 2021-11-03 14:52:58 +03:00
parent 4ef06a3a74
commit b8914651c0
1 changed files with 139 additions and 0 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

139
OpenID_Connect.md Normal file
View File

@ -0,0 +1,139 @@
# OpenID Connect
## Вводная информация
На данный момент серьезной проблемой для международных компаний при ведении бизнеса на территории Российской Федерации является использование глобальных веб-сайтов.
В соответствии с местным законодательством, зарубежные веб-сайты не могут обрабатывать персональные данные граждан Российской Федерации без их первоначального сбора и обработки в локальных базах данных.
Решением данной проблемы является использование сервера, размещенного на территории Российской Федерации, который будет осуществлять сбор необходимых данных, их обновление, хранение, а также будет давать возможность конечным пользователям изменять внесенные данные, отзывать согласия и т.д.
Таким решением, решающим проблему локализации персональных данных, является разработанная нами система.
Система предусматривает работу по протоколу OpenID Connect в соответствии со стандартом [OpenID Connect Core 1.0](https://openid.net/specs/openid-connect-core-1_0-final.html).
Перейдя по ссылке на спецификацию можно изучить основную функциональность OpenID Connect: аутентификацию, построенную на базе [OAuth 2.0](https://oauth.net/2/), и использование формул для передачи информации о конечном пользователе.
Также в рамках системы развернута конфигурация staging-окружения (https://staging.ps.radium-it.ru/.well-known/openid-configuration), в рамках которого возможно тестирование работы сервера авторизации oidc.
Важно отметить, что адрес production-сервера будет отличен от staging-окружения.
Для настройки брендированного адреса сервера авторизации oidc, например, https://client.privacy.ru или https://client.ps.radium-it.ru вам потребуется создать CNAME-запись на DNS-сервере нужного домена.
Кроме того, система предполагает наличие конечной точки jwks_endpoint, предоставляемой сервером авторизации oidc, с которой могут быть получены открытые ключи для проверки подписи подписанных JWT (https://staging.ps.radium-it.ru/.well-known/jwks.json).
Вся необходимая информация относительно конфигурации доступна по [ссылке](https://ldapwiki.com/wiki/Openid-configuration).
Далее будет представлен более подробный механизм работы системы по протоколу OpenID Connect, примеры запросов, потоков данных и т.д.
Мы предоставляем возможность изучить нашу систему и опробовать работу в конфигурации по описанному алгоритму.
## Схема работы протокола OpenID Connect Core 1.0
### Этап 1. Посещение зарубежного сайта
Когда пользователь заходит на веб-сайт, веб-сайт определяет, знаком ли этот пользователь веб-сайту или он заходит на сайт впервые.
Проверка осуществляется путем анализа GET-запроса от пользователя на наличие cookie-файлов.
В случае, если по cookie-файлам было определено, что пользователь уже посещал данный веб-сайт, то ему представляется доступ `grant access`.
Если никакие данные о пользователе не найдены, веб-сайту необходимо установить личность пользователя.
Для этого веб-сайт перенаправляет пользователя на сервер авторизации oidc и включает в запрос Сlient ID, Redirect Uri, Response Type и одно или несколько Scopes (разрешений), которые ему необходимы (см. рисунок 1).
```
GET https://staging.ps.radium-it.ru/oidc/authorize?scope=openid&redirect_uri=website/cb&client_id=AC!8&response_type=id_token"
Host: ps.radium-it.ru
```
*Рисунок 1. Диаграмма первого шага, когда пользователь заходит на веб-сайт*
Вместе с запросом от веб-сайта сервер авторизации oidc получает cookie-файлы, и на основании полученных данных решает - авторизован данный пользователь или нет.
Если конечный пользователь уже был авторизован, то autorization_endpoint спрашивает у базы данных, было ли получено согласие пользователя для этого веб-сайта.
Если согласие для этого сайта еще не было дано пользователем, то сервер авторизации oidc выводит форму Consent (подтверждения) с перечнем всех Scopes (разрешений), запрашиваемых веб-сайтом, а также с чекбоксом для подтверждения согласия на обработку персональных данных.
На странице пользователь видит форму для заполнения данных и следующий текст **(В ИДЕАЛЕ ДОБАВИТЬ РИСУНОК С ДЕМО ВЕРСИЕЙ СТРАНИЧКИ/Рисунок 2)**:
> Сайт example.client.ru запрашивает доступ к вашим данным: ID, email
>
> Разрешить доступ к данным?
>
> [X] Согласие
>
> [Разрешить / Submit]
Как только пользователь нажимает [Разрешить / Submit], Consent записывается в базу данных `sub+client_id+date+scope` и пользователь тут же перенаправляется с сервера авторизации oidc обратно на тот веб-ресурс, куда он хотел попасть (см. рисунок 3).
```
HTTP/1.1 302 Redirect
Location: {redirect_uri}
```
*Рисунок 2. Диаграмма потока данных, когда пользователь авторизован на веб-ресурсе*
Если же сервер решает, что пользователь никогда не был авторизован, то сервер авторизации oidc просит конечного пользователя авторизоваться.
Переходим к этапу 2.
### Этап 2. Посещение страницы авторизации и ввод первичных данных
Сервер авторизации oidc выводит форму Consent (подтверждения) с перечнем всех Scopes (разрешений), запрашиваемых веб-сайтом.
На странице пользователь видит форму для заполнения данных и следующий текст **(В ИДЕАЛЕ ДОБАВИТЬ РИСУНОК С ДЕМО ВЕРСИЕЙ СТРАНИЧКИ/см. рисунок 2)**:
> Сайт example.client.ru запрашивает доступ к вашим данным: ID, email.
>
> Если вы разрешаете доступ к данным, введите данные в отмеченные поля и нажмите [Разрешить / Submit]
>
> [] Согласие
>
> | Введите ваш email |
Помимо заполнения поля для ввода email пользователь также проставляет галочку в чекбоксе, подтверждая тем самым свое согласие на обработку персональных данных.
После того, как пользователь ввел email в форму, проставил галочку в чекбокс и нажал кнопку [Разрешить / Submit], он видит страницу со следующим содержанием **(В ИДЕАЛЕ ДОБАВИТЬ РИСУНОК С ДЕМО ВЕРСИЕЙ СТРАНИЧКИ/Рисунок 4)**:
> Спасибо за предоставленные данные, проверьте указанную электронную почту.
В тот момент, когда пользователь нажимает кнопку [Разрешить / Submit], на сервер авторизации oidc отправляется запрос о необходимости отправить пользователю *magic link*, в следствии чего сервер авторизации oidc уже со своей стороны отправляет на указанную почту письмо, содержащее *magic link* и следующий текст **(В ИДЕАЛЕ ДОБАВИТЬ РИСУНОК С ДЕМО ВЕРСИЕЙ СТРАНИЧКИ/Рисунок 5)**:
> Если вы хотите получить доступ к веб-ресурсу, перейдите по ссылке ниже:
>
> *magic link*
### Этап 3. Поиск имеющихся данных о пользователе
Когда пользователь переходит по ссылке *magic link*, он на самом деле осуществляет GET запрос по [*magic link*] на сервер авторизации oidc.
Таким образом, сервер авторизации oidc видит, что пользователь подтвердил, что он разрешает веб-сайту доступ к своим персональным данным.
При получении GET запроса по [*magic link*], сервер авторизации oidc создает в базе данных уникальный и никогда непереназначаемый идентификатор, основанный на только что полученных данных `sub+client_id+scope+consent_data`.
Так как одного email не достаточно для корректной работы с веб-сайтом, сервер авторизации oidc постарается запросить у сторонних баз данных (БД) известные сведения о данном пользователе, для этого сервер авторизации oidc отправляет GET запрос по [*email*].
Если на сервер авторизации oidc от какой-либо БД возвращается перечень необходимых сведений о пользователе, то эти данные сохраняются в таблицу User Info и пользователь переадресовывается на адрес веб-сайта, указанный ранее в redirect_uri (см. рисунок 6).
### Этап 4. Заполнение формы согласия
В случае, если сервер авторизации oidc не получил никакого ответа, после перехода по ссылке *magic link* в письме пользователь видит форму согласия на обработку персональных данных Consent Collection, в которой помимо предзаполненного поля с введенным ранее email, содержатся также дополнительные поля, например: [имя], [фамилия], [место работы] и т.д.
Все данные, собранные с помощью данной формы, также сохраняются в таблицу User Info (см. рисунок 6).
*Рисунок 6. Диаграмма потока данных при сборе данных о пользователе*
### Этап 5. Выдача JWT
После того, как все необходимые данные о пользователе собраны, сервер авторизации oidc отправляет пользователю следующий ответ, содержащий ссылку на веб-сайт и id_token (JWT - JSON Web Token):
```
HTTP/1.1 302 Redirect
Location: {redirect_uri}?id_token
```
При этом id_token (JWT) представляет из себя JSON файл, содержащий информацию, необходимую для аутентификации и проверки достоверности информации и веб-сайт может извлечь из JWT различную информацию, такую как ID, имя пользователя, время входа в учетную запись, срок окончания действия ID Token'а, наличие попыток вмешательства в JWT, например, `sub+email+collected_data+signature`.
Signature содержит в себе закрытый ключ, которым сервер авторизации oidc подписывает конкретный JWT.
Чтобы продолжить работу с данными веб-сайт должен проверить подписанный JWT, для этого он обращается к конечной точке jwks_endpoint, с которой может получить открытые ключи для проверки подписи JWT.
Цель достигнута.
Теперь веб-сайт может использовать id_token (JWT) для получения необходимой информации о пользователе.
**ВАЖНО:**
1. Все действия пользователь должен осуществлять в одном браузере = с одного устройства.
Использование нескольких устройств помешает успешному прохождению авторизации.
2. На Этапе 2 пользователю можно предложить ввести не email, а, например, номер телефона или оба варианта.
Тогда на следующих этапах будет возможность выбрать наиболее удобный способ коммуникации при отправке *magic link*.
3. На данный момент на сервере авторизации oidc сведения о сессии конкретного пользователя на веб-сайте (cookies) хранятся в течении 30 дней, однако при необходимости данный срок может быть увеличен.