XACML
Розши́рювана мо́ва розмі́тки контроля доступу (англ. eXtensible Access Control Markup Language, XACML) — стандарт, що визначає декларативну атрибутно-орієнтовану мову[2] для визначення до дрібниць правил контролю та управління доступом, архітектуру та модель обробки, яка описує як обробляти запити доступу згідно визначених правил та політик.
| XACML | |
|---|---|
| Парадигма | Декларативне програмування |
| Дата появи | 16 квітня 2001[1] |
| Творці | Саймон Блеквел |
| Розробник | Organization for the Advancement of Structured Information Standards (OASIS) |
| Основні реалізації | SunXACML, Axiomatics |
| Діалекти | ALFA (XACML) |
| Під впливом від | XML, SAML |
| Вплинула на | ALFA (XACML) |
| Ліцензія | OASIS |
| Звичайні розширення файлів |
.xml , .alfa |
| Вебсайт | oasis-open.org/committees/tc_home.php?wg_abbrev=xacml |
Одним із завдань виданої специфікації стандарту XACML є сприяння у створенні єдиної термінології та сумісності між імплементаціями різних виробників. XACML є переважно атрибутно-орієнтованою системою контролю доступу[en] (англ. Attribute-Based Access Control, ABAC), де атрибути (біти даних) асоційовані з користувачем, дією, або додатком є вхідними даними для прийняття рішення щодо можливості конретного користувача отримати доступ до вказаного ресурсу певним способом. Керування доступом за допомогою ролей також може бути імплементовано в XACML як різновид ABAC.
Модель XACML підтримує та сприяє розділенню місць прийняття рішення щодо можливості доступу та місця безпосереднього використання. Якщо визначення прав доступу вбудовано у клієнський додаток (або доступ базується на ідентифікаторах локальних користувачів та списках контролю доступу (англ. Access Control Lists, ACL), то у такій реалізації буває дуже складно змінити критерій доступу якщо змінюються основні правила або політики. Коли клієнт відокремлений від місця прийняття рішення щодо доступу, політики авторизації можуть бути змінені та застосовані для всіх клієнтів одночасно на льоту.
Історія ред.
Версію 1.0 було ратифіковано OASIS standards organization у 2003.
Версію 2.0 було ратифіковано OASIS standards organization першого лютого 2005.
Першу специфікацію комітету XACML 3.0 було видано десятого серпня 2010.[3] Останню версію XACML 3.0 було стандартизовано у січні 2013.[4]
Архітектура ред.
Термінологія ред.
Не нормативна термінолоія (згідно з RFC 2904, за виключенням PAP)
| Термін | Опис |
|---|---|
| PAP | Місце керування політиками (Policy Administration Point) — Місце керування політиками авторизації доступу |
| PDP | Місце вирішення політик (Policy Decision Point) — Точка що оцінює запити на доступ з огляду на політики авторизації до прийняття рішення щодо надання доступу |
| PEP | Місце застосування політик (Policy Enforcement Point) — Точка перехоплення запитів користувачів до ресурсу. Створює запит на прийняття рішення до PDP з метою отримання рішення щодо доступу (тобто доступ надано або відмовлено). Та реагує згідно отриманого рішення |
| PIP | Місце інформації щодо політик (Policy Information Point) — Системний елемент який є джерелом значень атрибутів (тобто ресурс, суб'єкт, оточення) |
| PRP | Місце видачі політик (Policy Retrieval Point) — Місце де зберігаються політики авторизації на XACML, зазвичай база даних або файлова система |
Потік ред.
- Користувач надсилає запит який перехоплено PEP
- PEP перетворює запит у авторизаційний запит XACML
- PEP перенаправляє авторизаційний запит до PDP
- PDP оцінює авторизаційний запит згідно з політиками за якими він налаштований. Політики отримуються за допомогою Policy Retrieval Point (PRP) та керуються за допомогою Policy Administration Point (PAP). Якщо потрібно, то отримує значення атрибутів з Policy Information Points (PIP).
- PDP приймає рішення (Дозволити / Відмовити / Не застосовується / Не визначено) та повертає його до PEP
Елементи політик ред.
Структурні елементи ред.
XACML має три рівні структурних елементів:
- PolicySet — набір політик,
- Policy — політика,
- Rule — правило.
Набір політик може містити довільне число політик та їх наборів. Політика може містити будь-яку кількість елементів правил.[5]
Атрибути та категорії ред.
Політики, набори політик, правила та запити — всі використовують суб'єкти, ресурси, оточення та дії.
- Елемент суб'єкт є сутністю, що запитує доступ. Суб'єкт має один або більше атрибутів.
- Елемент ресурс це дані, сервіс або компонент системи. Ресурс має один або більше атрибутів.
- Елемент дія визначає тип запиту з надання доступу до ресурса. Дія має один або більше атрибутів.
- Елемент оточення може опціонально надавати додаткову інформацію.
Цілі ред.
XACML визначає ціль,[6] яка зазвичай є набором спрощених умов для суб'єкта, ресурсу або дії, що мають бути задоволені набором політик, політикою або правилом та застосовані до конкретного запиту. Як тільки визначено політику або набір політик, що стосуються даного запиту, її правила обчислюються щоб визначити рішення щодо надання доступу та відповідь.
Окрім того, що цілі визначають застосовуваність, інформація щодо цілей надає спосіб індексації політик. Що особливо корисно якщо потрібно зберігати багато політик, а потім швидко переглянути їх з метою визначення того яку застосувати. Коли приходить запит на надання доступу, PDP буде знати де шукати політики, які можуть бути застосовані до даного запиту оскільки політики індексуються згідно з їх цільових обмежень. Зауважте, що ціль може визначати, що вона повинна застосовуватись до кожного запиту.
Набори політик, політики та правила всі містять цільові елементи.
Умови ред.
Умови існують лише у правилах. Умови загалом є розширеною формою цілі, що може використовувати більш широкий діапазон функцій та, що більш важливо, може використовуватись для порівняння двох або більше атрибутів, тобто subject-id==doctor-id. За умови, що можливо імплементувати розподіл обов'язків перевірки керування доступом на основі ролей.
Обов'язки ред.
Разом з XACML застосовується концепція обов'язків. Обов'язком є вказівка від Місця вирішення політик (PDP) до місця застосування політик (PEP) з приводу того що має відбуватись до або після того як доступ надано. Якщо PEP не може виконати директиву, надання доступу не може або не повинно бути реалізоване. Збільшення обов'язків нівелює прогалину між формальними вимогами та дотриманням політики. Приклад обов'язку наведено нижче:
Правило керування доступом:
Дозволити доступ до ресурсу MedicalJournal з атрибутом patientID=x
якщо Суб'єкт збігається з DesignatedDoctorOfPatient
та дія прочитати
з обов'язками
при наданні доступу: doLog_Inform(patientID, Суб'єкт, час)
при відмові у доступі : doLog_UnauthorizedLogin(patientID, Суб'єкт, час)
XACML's обов'язки можуть слугувати ефективним способом задоволення формальних вимог (наприклад, не відмова) таких, які важко реалізувати за допомогою правил керування доступом. Більше того, будь-які формальні вимоги будуть частиною політики керування доступом як обов'язків та не як окремих функцій, що робить політики узгодженими та дозволяє досягти централізації IT-середовища простішим способом.
Посилання ред.
- ↑ Best, Karl (16 April 2001). OASIS TC call for participation: XACML. OASIS. Архів оригіналу за 1 листопада 2016. Процитовано 31 October 2016.
- ↑ pure-xacml. www.axiomatics.com. Архів оригіналу за 22 жовтня 2016. Процитовано 6 лютого 2017.
- ↑ XACML 3.0 - committee specification 01. OASIS (oasis-open.org). Архів оригіналу за 25 лютого 2021. Процитовано 10 серпня 2010.
- ↑ eXtensible Access Control Markup Language (XACML) V3.0 approved as an OASIS Standard [Архівовано 4 грудня 2019 у Wayback Machine.], eXtensible Access Control Markup Language (XACML) V3.0 approved as an OASIS Standard.
- ↑ Архівована копія (PDF). Архів оригіналу (PDF) за 7 лютого 2017. Процитовано 7 лютого 2017.
{{cite web}}: Обслуговування CS1: Сторінки з текстом «archived copy» як значення параметру title (посилання) - ↑ Архівована копія. Архів оригіналу за 11 березня 2017. Процитовано 7 лютого 2017.
{{cite web}}: Обслуговування CS1: Сторінки з текстом «archived copy» як значення параметру title (посилання)