Проблема

Базові дозволи Keycloak надаються за допомогою ролей, присутніх в системних клієнтах. У більшості випадків використовується клієнт realm-management. Однак, наявні дозволи є негнучкими та надають забагато доступу. Ви можете надати користувачу право керувати усіма користувачами в realm або не керувати ніким.

У цьому випадку є два можливі сценарії роботи. У першому, лише обмежена кількість розробників має доступ до realm, що робить їх відповідальними за його управління. Або надати доступ кожному розробнику, дозволяючи їм бачити дані ваших клієнтів. Жоден із них не можна вважати оптимальним підходом. Було б добре мати спосіб надавати доступ лише до обмеженої кількості користувачів, приховуючи дані інших. Саме це, і не тільки, дозволяють робити Fine-Grained Admin Permissions.

Fine-Grained Permissions

Згадані Fine-Grained Admin Permissions (FGAP) базуються на Fine-Grained permissions, що з’явилися в Keycloak 26.2.0. Ця функція дозволяє винести автентифікацію користувача з додатку та делегувати її для Keycloak. Перед налаштуванням Fine-Grained Admin Permissions, розглянемо ключові компоненти, що використовуються в обох функціях.

Сервер ресурсу (Resource server) – це застосунок, який містить доступні ресурси. Ресурс (Resource) – це все, що ви хочете захистити. Ресурсом може бути файл в об’єктному сховищі, запис із бази даних, або API. Кожен ресурс може мати набір необов’язкових сфер застосування (Scopes), які визначають набір дозволених дій. Доступ може бути наданий залежно від умов, визначених у політиках (Policies).

Політики не прикріплюються до ресурсів безпосередньо, натомість дозволи (Permissions) є з’єднувальною ланкою, що їх поєднує. Цей підхід робить систему гнучкою, дозволяючи комбінувати політику з різними ресурсами. Вони можуть застосовуватися до конкретної сфери застосування (scope) або до самого ресурсу, надаючи повний контроль над ним.

Конфігурація Terraform

Функція Fine-Grained permissions повністю підтримується в офіційному Terraform Provider v5.7.0. Він дозволяє версіонувати конфігурацію та миттєво застосовувати її. Інтеграція із Terraform провайдером значно розширює функціонал Keycloak та робить його повноцінною заміною для OPA policy agent.

Admin Permissions

Тепер, коли ми ознайомилися з Fine-Grained Permissions, розгляньмо Fine-Grained Admin Permissions. Очевидно, що сервер ресурсу (resource server) у цьому сценарії – це сам Keycloak. Він має набір попередньо визначених ресурсів з їхніми scopes: Users, Groups, Clients та Roles. Ми можемо створювати політики та дозволи для керування доступом до даних ресурсів.

Реальний приклад

Розглянемо реальний приклад механізму імперсонації. Імперсонація у Keycloak надає доступ до облікового запису без облікових даних користувача. Вона корисна для тестування та відтворення помилок. З базовими дозволами неможливо обмежити вибірку користувачів доступних для імперсонації, що може призвести до зловживання правами у застосунках.

Найкращий варіант – використовувати Fine-Grained Admin Permissions для надання гранулярного доступу. Для цього потрібно лише два кроки. Створити політику, щоб визначити: «Хто може імперсонувати?» І створити дозвіл, який дозволяє імперсонацію лише для обмеженого набору користувачів, група test-users у цьому прикладі. Перш за все, необхідно увімкнути Fine-Grained Admin Permissions:

У наведеному нижче прикладі використовується Group Policy, щоб дозволити доступ лише користувачам, які є членами dev-group.

Після створення політики, настав час створити Group Permission зі Scope impersonate-members.

Тепер розробники можуть імперсонувати лише обмежену вибірку тестових облікових записів.

Виклики

Fine-Grained Admin Permissions – це нова функція, яка значно розширює сфери застосування Keycloak. Через свою новизну, функція має кілька підводних каменів, що створюють нові виклики. У цьому розділі ми розглянемо два з них.

Обмежена підтримка Terraform

Попри те, що функція FGAP базується на Fine-Grained permissions, вона реалізує власний окремий API. Це розділення погано впливає на підтримку Terraform провайдером. Наразі він дозволяє лише увімкнути функцію на рівні realm. Дозволи та політики можна створювати лише через UI або API-виклики. У офіційному репозиторії, є створене issue щодо цієї проблеми. Однак, на поточний момент, остаточна дата реалізації залишається невідомою.

Помилки

Як і будь-яка нова функція, вона може містити помилки, що не були виявлені під час етапу тестування. Наприклад, Keycloak 26.2.0 має помилку, яка ігнорує Fine-Grained Group Permissions під час створення нового користувача. Це дозволяє додати нового користувача до груп з обмеженим доступом.

Розглянута помилка згадана у обговоренні з репозиторію Keycloak (детальна конфігурація FGAP описана в обговоренні). На Рисунку 5 зображена ієрархія груп тестового realm. У наведеній конфігурації, користувачі з GroupA мають найнижчі права. Вони не можуть додавати нові облікові записи до дочірніх груп та виконувати будь-які зміни над ними.

Після авторизації з обліковим записом користувача GroupA, існує можливість обійти FGAP та додати нового користувача до GroupC. Дія може бути виконана лише під час виконання запиту на створення нового облікового запису у системі (Рисунок 6).

На щастя, Keycloak не дозволяє встановити пароль для нового користувача одразу у меню створення. Активація користувача вимагає створення тимчасового пароля або надсилання повідомлення «Reset password». Дані дії відбуваються уже після створення і є забороненими конфігурацією FGAP для користувача GroupA. Спроби виконання зазначених запитів закінчуються помилкою 403.

Висновок

Функція Keycloak Fine-Grained Admin Permissions вирішує давню проблему: як делегувати адміністративний доступ без надмірного розкриття конфіденційних даних. Замість підходу «все або нічого» з базовими дозволами, доступ тепер можна обмежувати за допомогою гнучкого налаштування політик FGAP. Це дозволяє безпечно делегувати відповідальність, захищаючи при цьому дані клієнтів. З підтримкою Terraform, FGAP незабаром перетворить Keycloak на потужну платформу для контролю доступу, відкриваючи нові сфери застосування додатка.