По какому принципу работает SSO и распределения прав (на примере keycloak)?
Стоит задача реализовать технологию единого входа на базе Keycloak. Прошу помощи разобраться с обработкой прав и ролей приложением (клиентом). Гугл не дал четкого представления о логике работы. Буду благодарен любым комментариям.
Как это вижу я упрощенно:
1. Приложение(клиент) посылает запрос в Keycloak c id клиента и учетными данными пользователя, выполняющего вход.
2. В случае корректной авторизации на сервере единого входа клиент получает ответ в виде token, refresh token и другой информации. Возможно среди них будет и username пользователя, его email и т.д, но вроде как это после еще одного запроса.
3. Далее как раз суть моего вопроса - непонятно, что делать с этими данными, точнее где управлять доступами к разным частям приложения. Допустим, роль admin имеет право просматривать страницу "/users", в то время как роль guest нет. Где именно должна быть обработка разрешений для конкретной роли: на бэкэнде или именно на Keycloak? Ну или как-то вообще по-другому.
4. Надо ли как-то прошедшего авторизацию в keycloak пользователя сохранять в таблицу user приложения?
Поясните плиз где неправильно думаю и если не сложно, то как надо в паре слов. Спасибо заранее)
да, вам нужно отправить запрос, содержащий реалм, идентификатор клиента в этом реалме и данные достаточные для получения токена (к примеру grant_type="password", username, password, client_secret)
да, он получает access_token и refresh_token. Вы можете декодировать токен и посмотреть что в нем храниться и вытащить данные которые вам нужны к примеру в нем хранятся роли и username, при этом можно положить туда дополнительную инфу
проверка разрешений на беке, для простоты ищете что-то на подобии spring-security, но для php, который будет проверять ваш токен и роли в нем, и в зависимости от роли будете отдавать либо 200 либо 401 на запрос к которому у пользователя нет доступа
если вам не нужно связать какие-то данные вашего приложения с идентификатором пользователя в кейклоке, то не нужно
Спасибо, что разжевали. Единственное не особо понятно на счет п.4. Например, в приложении пользователь с определенными правами будет иметь возможность вставлять какие-то данные. В этих данных, допустим, будет содержаться id того пользователя, который их вставил, возможно нужно еще отобразить его имя где-нибудь в интерфейсе. В таком случае нужно ли сохранять пользователей с кейлока?
Вообще в одной из библиотек к фреймворку, на котором реализую, предложено решение в виде двух таблиц: 1-я это те пользователи, которые прошли регистрацию непосредственно через приложение, а 2-я которые авторизовались через OAuth.
Если вам нужно отобразить имя и фамилию имея на руках идентификатор пользователя в кейклоке, то да, вам бы иметь связь этих данных в вашей базе с этим идентификатором
Можно конечно сходить в кейклок и спросить у него имя пользователя по идентификатору, но это будет нерационально
rukbrook, сори, забыл еще важный момент! После прохождения авторизации я получаю токен авторизации, а в месте с ним и все необходимые данные. Мне все это дело хранить в сессии или при каждом запросе пользователя сперва идет взаимодействие с кейклоком или же к кейклоку идет обращение только после истечения срока действия токена?
у вас есть access_token с временем в течении которого он действителен, все это время вы ему доверяете, после того как он протух, вы можете обновить токен с помощью refresh_token, если все нужные для вас данные вы можете получить из токена, то дергать кейклок при каждом запросе я не вижу большого смысла
Средний
