XACML Obligations are explanation or ask for more condition

Question

In XACML, I am not sure if Obligations add more information or give more condition to rule decision. For example, I would like the response permits an access to a patient Electronic Health Record, BUT I would like to add obligations to deny access to specific records in the patient Electronic Health Record.

Answer 1

In XACML, obligations (and advice) are meant to enrich the response the PEP receives back from the PDP. They are not meant to convey authorization logic.

Examples

Two-factor authentication

This example revolves around trust / authentication elevation.

• Q: Can I transfer $5,000 from A to B using basic authentication?
• A: Deny. Reroute user to two-factor authentication page to elevate authentication
• Q: Can I transfer $5,000 from A to B using two-factor AuthN?
• A: Permit + obligation send email to sender.

Break The Glass

• Can Alice view medical record #123?
• Deny + obligation: if this is an emergency then wave the 'emergency flag' and request access again.
• Can Alice view medical record #123? This is an emergency.
• Permit + write inside the hospital the log the fact Alice saw record #123 and claimed this was an emergency.

The aforementioned example comes from the break-the-glass scenario that occurs in healthcare.

Controlling access to a hierarchy of things (items, records)

In your example, you want to control access to items and sub-items. For instance an EHR is made up of PII, PHI, and financial information. Can a doctor view a patient's EHR they have a relationship with? Yes they should be able to. But you'd like to mask or redact the financial information as it is irrelevant to the doctor.

In that type of scenario, I would write different rules - one per sub-item. I want the authorization logic to be visible. I want to know there is a rule about doctors viewing PII, PHI, or financials.

I would potentially use the Multiple Decision Profile to ask questions on the different parts of the record.

Of course, if all you want to do is systematically mask just the one field, then you could get away with an obligation.

Best Practice

When you write obligations and advice, you should try not to hide authorization logic inside them. Use them to enrich authorization flows.