Subject: XACML input for Trust Elevation document
4.3.3 XACML Authorization Model
The eXtensible Access Control Markup Language (XACML) standard defines a reference architecture for Attribute-Based Access Control (ABAC), a language for expressing access control rules and policies, and a protocol for generating and processing access control requests and returning responses.
Access to resources is mediated by a Policy Enforcement Point (PEP), which relies on decisions from a Policy Decision Point (PDP). When a user attempts to access a protected resource, the PEP assembles a request, which provides attributes about the user, the resource, the environment, and the action requested. The PEP communicates the request to the PDP, which evaluates it according to pre-defined policies.
To perform Trust Elevation, the access control policy can specify how users must be authenticated, including parameters such as authentication method, credentials accepted, and levels of assurance. Trust elevation in this context means enhancing authentication and/or authorization by means of requiring additional attributes.
Consider the following example: a user requests access to a protected resource. The access control policy governing the resource requires multi-factor authentication using a strongly vetted identity credential by means of setting the MustBePresent attribute to TRUE. The PEP controlling access to the resource has only hitherto validated the user identity by means of a lower assurance username/password combination. When the PEP initially formulates the request, it bases the user identity attribute on the previous username/password authentication event. When the PDP receives the request, it evaluates the request according to the appropriate policy, based on the resource. Since MustBePresent = TRUE, the PDP renders an “Indeterminate” decision, with a status code of “urn:oasis:names:tc:xacml:1.0:status:missing-attribute”. Upon receiving this “Indeterminate” with MissingAttribute status decision from the PDP, the PEP may resubmit a request after acquiring the proper attributes. In this case, the proper attributes could only be gathered through a step-up authentication event. This sequence constitutes a sample Trust Elevation event.
Alternatively, security administrators and resource owners may devise a series of Boolean attributes to test for authentication methods used, i.e.:
This would allow policy authors to specify which methods are acceptable by testing for a TRUE result among the list they define as meeting security requirements.
Lastly, the Obligation element of XACML could be used to perform Trust Elevation. Any rule that permits access and specifies the authentication level required would add an obligation stating the minimum required authentication level. e.g.,
if “User authorized” then Permit. FulfillOn=Permit -> authenticated-by-two-factors-obligation.
In this case, the PEP does not need any special attributes. It makes a normal authorization request. If the response is Deny or NotApplicable, then the authentication level is irrelevant because the user is not allowed access. If the response is Permit without any authentication level obligations, then access is allowed even at the lowest authentication level. If the response is Permit with specific authentication level obligations, then the PEP must perform step-up authentication to the authentication level of the highest level of the obligations it received. If the highest level is satisfied, then any lower levels are satisfied. If that step-up fails or cannot be attempted, then access is denied. If step-up succeeds then access is allowed without needing an additional authorization request.
4.3.4 SAML Backend Attribute Exchange (BAE) Model
The Security Assertion Markup Language (SAML) standard defines a means for representing authentication events between different trusting security domains. A SAML assertion may contain a variety of attributes about the requesting subject and the conditions of the authentication event. Subject and Issuer attributes generally relate the name of the subject and the name of the organization with which the subject is associated in the AuthenticationStatement element. The AuthenticationStatement also contains an AuthenticationContext attribute, which details how the subject was authenticated in the context of the current assertion.
SAML-aware relying party applications can request additional attributes via the AttributeQuery element. Moreover, SAML authorities can request full attribute evaluations via the AuthzDecisionQuery element. Relying parties may specify acceptable authentication methods and credentials by using the RequestedAuthnContext element, and can force a fresh authentication event by setting ForceAuthn to true.
Trust Elevation can be exemplified in the following scenario using SAML: a user attempts to access content protected by a SAML-aware relying party (RP) application. The user posts a SAML assertion containing Subject/Issuer attributes and indicates a low level assurance authentication event to the RP. The RP’s access control policy requires additional attributes and a higher strength credential and authentication event. The RP initiates a SAML authentication request to the user’s home domain. This forces a step-up authentication event and retrieval of additional attributes, as required by the attribute contract. As with the XACML model, trust elevation means enhancing authentication and/or authorization by means of requiring additional attributes.