Часто задаваемые вопросы
Где происходит валидация токенов?
Валидацией токенов занимается gatekeeper. Он проверяет, истек срок действия token'a или нет. Если истек, проверяет refresh token, если он валиден и срок его действия не истек, получает новый access token.
Протокол по которому должно происходить взаимодействие (возможно https)?
Да
Какое время жизни access token и refresh token?
Это настраивается в нашем Keycloak для ADCP. Можно настроить требуемое вам время жизни refresh token и access token (базово refresh - 30 мин, access - 1 мин)
Зачем нужен gatekeeper?
Это точка интеграции между нашей системой и Keycloak
На стороне компании уже есть Keycloak, зачем использовать второй?
Несколько причин:
- единообразие поставки для систем группы,
- для упрощения интеграций (доступ нужно будет настроить только до сервера с нашим кейклоком),
- возможность в будущем создавать и использовать служебные учётки для внутренних сервисов, использовать последние версии keycloak.
Что такое Vaultee OIDC Provider?
Компонент Vaultee OIDC Provider (AOP) — это наш собственный провайдер идентификации (IDP). Он не используется в целевой схеме, если вместо него требуется использовать иной IDP (Keycloak, Microsoft, Google и т.п.).
Какой функционал и какие функции доступны пользователю после прохождения аутентификации?
После прохождения аутентификации пользователю доступна только та функциональность, которая предоставляется согласно его ролям в системе. В диаграмме последовательности часть "пользователь просит показать информацию о своем профиле" добавлена только ради демонстрации того, как обрабатывается каждый запрос к GraphQL Server'у.
Каким образом в Auth Service появляется информация о пользователях и ролях?
Информация о пользователях в Auth Service появляется после его регистрации в системе. Сразу после регистрации у пользователя ролей нет, роли будут назначены администратором.
Что входит в проверку 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 истек).*Отличается ли процесс проверки запросов GraphQL Server от общей проверки Gatekeeper?
Нет. Единственное отличие - вместо redirect GraphQL API будет отдавать status code 401.
Где будут храниться токены?
Access_token всегда будет храниться в cookies под названием “kc-access” в зашифрованном виде. Refresh_token можно хранить в cookies в зашифрованном виде под названием “kc-state” либо в Redis в зависимости от настроек деплоя. Принята схема хранения в cookies.