Obligations

In the eXtensible Access Control Markup Language (XACML), the Policy Decision Point (PDP) evaluates and issues a decision about whether an access request should be permitted or denied. This decision is sent to the Policy Enforcement Point (PEP) which protects the resources (such as a web service) by blocking or allowing access depending on the decision. So far, XACML resembles any conventional access control or authorization model.

Consider the following scenario in a medical journal system: only the designated doctor of a particular patient must be allowed access to the records of the patient.

Access control rule:
Allow access to resource MedicalJournal with attribute PatientID=x
if Subject match DesignatedDoctorOfPatient
and action is read.

However, there may be situations where this is not enough. In health care systems, non-repudiation and logging are desirable formal requirements, e.g. according to the Privacy Rule in HIPAA. This rule states that a patient must be informed when his medical record is accessed. If any such requirements are implemented in the protected resource (such as a database) instead of in the policy enforcement point, this can affect the possibility of centralizing the access control administration negatively because the formal requirements (e.g. the logging) will not be under the centralized administration's control. It could also lead to situations where logging is not possible but access will nevertheless be permitted (i.e. insufficient disk space or network problems) resulting in negligence of the requirements.

Therefore, when centralizing the security architecture with the XACML model, a concept called obligations can be used. An obligation is a directive from the PDP to the PEP on what must be carried out before or after an access is granted. If the PEP is unable to comply with the directive, the granted access will not be realized. The augmentation of obligations eliminates the gap between requirements and policy enforcement previously described. An use of obligations can look like the following:

Access control rule:
Allow access to resource MedicalJournal with attribute patientID=x
if Subject match DesignatedDoctorOfPatient
and action is read
with obligation on Permit: doLog_Inform(patientID, Subject, time)

The XACML's obligation can be an effective way to meet formal requirements in your organization that can be hard to implement as access control rules. Furthermore, any formal requirements will be part of the access control policy as obligations and not as separate functions, which makes policies consistent and centralization of the IT environment easier to achieve.

Go back