Attribute-Based Access Control (ABAC) uses attributes as building blocks in a structured language used to define access control rules and to describe access requests. Attributes are sets of labels or properties which can be used to describe all the entities that must be considered for authorization purposes. Each attribute consists of a key-value pair such as "Role=Assistant Manager".

Axiomatics implements ABAC using XACML, a standard that by default considers these four entities:

• The subject who is demanding access to an information asset.
  General attributes describing the subject, for instance assigned roles, group memberships, the department / company to which the user belongs, management level, certifications or competencies, user ID, etc., can often be retrieved from an HR system or directory (LDAP). These attributes are often already available in the token received from the authentication service used during login, for instance a SAML token.
• The action which the user wants to perform.
  Common action attributes in authorization request are "read" and/or "write". In more complex scenarios, the action may be described by a combination of several attributes. When you access your online bank the action may perhaps be described by multiple attributes such as "action type=transfer", "amount=$500", "credit account=123456".
• The resource identifying the information asset or object impacted by the action.
  Resource attributes render the characteristics that identify the information asset. In the online banking example above, the resource most likely is your "debit account=<your account number>", in a document management system, attributes typically correspond to the metadata or tags entered when the document is checked-in, in eHealth applications the resource is probably a part of the health record identified by the patient ID etc.
• The environment identifying the context in which access is requested.
  Common environment attributes are related to the current time and location from where access is requested, to the type of communication channel, such as protocol or encryption strength, or client type (PC, smart phone, etc.). Authentication strength may also be relevant to authorization. But context data can principally be of any type that is relevant to consider to minimize risks or to plan precautions: the number of transactions already made in the last 24 hours, normal user behavior patterns, relations to a third party, availability of related legal contracts etc.

Attribute evaluation enables policy-based authorization. Let's consider this example:

• A policy states that "all users belonging to the sales department should have read access to proposals sent to customers within the sales region to which the user belongs".
• An access request evaluation based on the following attributes and attribute values should therefore return PERMIT:
  Subject's "department"="sales"
  Subject's "sales region"="NW"
  Action="read"
  Resource "type"="proposal document"
  Resource "region"="NW"