Часто задаваемые вопросы

1. Где происходит валидация токенов?

   Валидацией токенов занимается gatekeeper. Он проверяет, истек срок действия token'a или нет. Если истек, проверяет refresh token, если он валиден и срок его действия не истек, получает новый access token.

2. Протокол по которому должно происходить взаимодействие (возможно https)?

   Да

3. Какое время жизни access token и refresh token?

   Это настраивается в нашем Keycloak для ADCP. Можно настроить требуемое вам время жизни refresh token и access token (базово refresh - 30 мин, access - 1 мин)

4. Зачем нужен gatekeeper?

   Это точка интеграции между нашей системой и Keycloak

5. На стороне компании уже есть Keycloak, зачем использовать второй?

   Несколько причин:

   • единообразие поставки для систем группы,
   • для упрощения интеграций (доступ нужно будет настроить только до сервера с нашим кейклоком),
   • возможность в будущем создавать и использовать служебные учётки для внутренних сервисов, использовать последние версии keycloak.

6. Что такое Vaultee OIDC Provider?

   Компонент Vaultee OIDC Provider (AOP) — это наш собственный провайдер идентификации (IDP). Он не используется в целевой схеме, если вместо него требуется использовать иной IDP (Keycloak, Microsoft, Google и т.п.).

7. Какой функционал и какие функции доступны пользователю после прохождения аутентификации?

   После прохождения аутентификации пользователю доступна только та функциональность, которая предоставляется согласно его ролям в системе. В диаграмме последовательности часть "пользователь просит показать информацию о своем профиле" добавлена только ради демонстрации того, как обрабатывается каждый запрос к GraphQL Server'у.

8. Каким образом в Auth Service появляется информация о пользователях и ролях?

   Информация о пользователях в Auth Service появляется после его регистрации в системе. Сразу после регистрации у пользователя ролей нет, роли будут назначены администратором.

9. Что входит в проверку Gatekeeper аутентифицирован ли пользователь или нет? Что он проверяет и как? После успешной аутентификации gatekeeper сохраняет kc-access (зашифрованный access_token) и kc-state (зашифрованный refresh_token) в cookies браузера. Gatekeeper считает пользователя не аутентифицированным, если:

   - *kc-access, kc-state отсутствуют в cookies браузера;*
   - *kc-access не удалось расшифровать gatekeeper’у (например, кто-то внес изменения руками в значение куки);*
   - *kc-access удалось расшифровать, но срок действия истек и нет возможности получить новый (например, если еще срок действия refresh_token’a истек).*

10. Отличается ли процесс проверки запросов GraphQL Server от общей проверки Gatekeeper?

    Нет. Единственное отличие - вместо redirect GraphQL API будет отдавать status code 401.

11. Где будут храниться токены?

    Access_token всегда будет храниться в cookies под названием “kc-access” в зашифрованном виде. Refresh_token можно хранить в cookies в зашифрованном виде под названием “kc-state” либо в Redis в зависимости от настроек деплоя. Принята схема хранения в cookies.