XACML

Розши́рювана мо́ва розмі́тки контроля доступу (англ. eXtensible Access Control Markup Language, XACML) — стандарт, що визначає декларативну атрибутно-орієнтовану мову^[2] для визначення до дрібниць правил контролю та управління доступом, архітектуру та модель обробки, яка описує як обробляти запити доступу згідно визначених правил та політик.

XACML
Парадигма	Декларативне програмування
Дата появи	16 квітня 2001; 24 роки тому (2001-04-16)[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]

Архітектура

Дане зображення показує архітектуру XACML та простий потік авторизації.

Термінологія

Не нормативна термінолоія (згідно з 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, зазвичай база даних або файлова система

Потік

1. Користувач надсилає запит який перехоплено PEP
2. PEP перетворює запит у авторизаційний запит XACML
3. PEP перенаправляє авторизаційний запит до PDP
4. PDP оцінює авторизаційний запит згідно з політиками за якими він налаштований. Політики отримуються за допомогою Policy Retrieval Point (PRP) та керуються за допомогою Policy Administration Point (PAP). Якщо потрібно, то отримує значення атрибутів з Policy Information Points (PIP).
5. 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-середовища простішим способом.