How Can I Use Time in a XACML Policy?

Attribute-based access control (ABAC) lets us define fine-grained authorization policies that typically take into account user attributes and resource attributes. Sometimes we may need time to express authorization constraints.

For example:

  • Only a supervisor can view the medical record of a patient during night time between 11pm and 6am.

So, how can we do this? Let’s take a closer look.

There are three main components defined by the XACML policy language specification: PolicySet, Policy and Rule. These elements are the building blocks of the XACML policies . When an authorization request is sent to a Policy Decision Point (PDP), Targets are used inside Policy and PolicySet elements to determine which policies the request applies to. Rules can also contain targets in order to determine which rules to evaluate for the authorization request being sent.

The time datatype

XACML inherits the data type from the XML schema which is defined in this document. The Abbreviated Language For Authorization (ALFA) also supports the time datatype.

The XACML identifier for the time datatype is http://www.w3.org/2001/XMLSchema#time and most common format used is HH:MM:SS. Another format that can be used is HH:MM:SS+OFFSET or HH:MM:SS-OFFSET, where OFFSET is the hours difference to GMT time zone. Also, note that using this format for midnight can be expressed both as 24:00:00 and 00:00:00.

Example attributes

Time attributes are great to express the time of day properties of certain objects used in access control. For instance, we may want to check whether a user is allowed to access a certain resource during night time. Another example could be the implementation of rules that allow specific access for maintenance purpose in certain time windows.

Time related functions in XACML and ALFA

The OASIS XACML Core Specification defines the following time related functions that are useful to deal with time attributes and that are also supported by ALFA:

  • timeInRange(a, b, c)
    • XACML identifier: urn:oasis:names:tc:xacml:2.0:function:time-in-range
    • ALFA identifier: timeInRange
    • Description: Returns boolean value “True” if the first specified value, a, falls inside the time range specified by the second, b, and third argument, c.
  • timeGreaterThan(a, b)
    • XACML identifier: urn:oasis:names:tc:xacml:2.0:function:time-greater-than
    • ALFA identifier:time-greater-than
    • Description: Returns boolean value “True” if the first argument, a, is greater than the second argument, b.
  • timeGreaterThanOrEqual(a ,b)
    • XACML identifier: urn:oasis:names:tc:xacml:2.0:function:time-greater-than-or-equal
    • ALFA identifier: timeGreaterThanOrEqual
    • Description: Returns boolean value “True” if the first argument, a, is greater than the second argument, b, or if they are equal.
  • timeLessThan(a ,b)
    • XACML identifier: urn:oasis:names:tc:xacml:2.0:function:time-less-than
    • ALFA identifier: timeLessThan
    • Description: Returns boolean value “True” if the first argument, a, is less than the second argument, b.
  • timeLessThanOrEqual(a ,b)
    • XACML identifier: urn:oasis:names:tc:xacml:2.0:function:time-less-than-or-equal
    • ALFA identifier: timeLessThanOrEqual
    • Description: Returns boolean value “True” if the first argument, a, is greater than the second argument,b , or if they are equal.

Policy example in ALFA

The ALFA language offers a lightweight and compact syntax to write XACML policies programmatically.

Below is a example of a simple policy written in ALFA that implements a time based access control requirement.

namespace exampleTime {
 attribute role {
    category = subjectCat
    id = "role"
    type = string


 attribute document{
    category = resource
    id = "doc"
    type = string


 policy checkTimeAccess {
    apply firstApplicable
      rule checkNightAccess {
        target clause role == "supervisor" and document = "medical_record"
        condition timeInRange(timeOneAndOnly(currentTime),
          "22:00:00":time,  "06:00:00":time)

The policy above contains a rule that checks whether the user trying to access the document “alfa” during night time (specifically between 22PM and 6AM) has the role “supervisor”. The currentTime attribute used in this example, a predefined attribute of the XACML specification is also pre-defined in ALFA and therefore does not have to be explicitly defined. The function timeOneAndOnly is necessary since the attribute currentTime is defined as a bag while the function requests a single value.

Note that the suffix “:time” is necessary in ALFA to convert the string containing the time value into the correct time datatype.


According to the XACML specification, if the value is not sent by the Policy Enforcement Point (PEP), it has to be provided by the PDP by reading the timestamp of the local server where the PDP is running. The argument against this approach is that in case of permitting or denying access to resources based on time of day, probably what is most important is where physically the access is performed as opposed to where the access decision is taken, which, for example, could be in a server in another time zone.


As discussed in this post, time attributes and functions provide great abilities in order to implement policies based on time constraints, temporary and specific access permissions, maintenance windows and so on.

Organizations dealing with implementations spread across several time zones need to take special care when dealing with time attributes, making sure that the PEPs are accessing the correct time information.

In conclusion, the capability of making access control decisions based on time of day constraints is one of the advantages of an ABAC oriented approach versus a traditional RBAC implementation.

Additional reading

Related Articles

Meeting today’s dynamic authorization and access challenges: The Axiomatics story | Dynamically Speaking
Dynamically Speaking
For more than 15 years, Axiomatics has worked with companies worldwide to define and deliver solutions to the most complex authorization and access challenge. In...
Getting started with Zero Trust using dynamic authorization | Dynamically Speaking
Dynamically Speaking
Zero Trust. It’s everywhere. It’s a methodology that’s been around for years, and we are now seeing a significant uptick in the number of enterprises...
The case for dynamic authorization in banking and finance
Attribute Based Access Control (ABAC)
More than other organizations, banks, and financial institutions face the highest levels of scrutiny when it comes to how they protect critical assets and sensitive...