Authorization decisions

Authorization decisions are essential in determining whether an access request should be granted, denied, or regarded as not applicable.

XACML

ADS (Access Decision Service) utilizes XACML to evaluate and make authorization decisions. XACML (eXtensible Access Control Markup Language) version 3.0 is the foundation of Axiomatics Authorization system, providing a standard framework for dynamic authorization management through Attribute-based Access Control (ABAC).

Attributes play a crucial role in this process, defining the conditions under which access is permitted or denied based on the subject, action, resource, and environment. When an application interacts with ADS to make authorization decisions, it sends a request and expects a response. This interaction involves exchanging data, and the format of this data is specified using content types. The content type tells ADS what format the incoming data (request) is in and also tells the application what format to expect the data (response) from ADS.

Content types

ADS supports three content types:

• application/xacml+json

• application/xacml+xml

• application/json

All three content types can be used for both requests and responses, and the request and the response can have different content types.

Requests and Responses

When an application sends a request to ADS to determine if a certain action is permitted, it can expect a response.

The following examples use curl. For more information on curl refer to https://curl.haxx.se/Opens in a new tab.

Request

The content type of the request is specified using the HTTP header content-type (or Content-Type, the headers are case-insensitive). This header is mandatory on each request. A non-valid header will result in HTTP 415 Unsupported media type.

curl --data @request.json -H content-type:application/xacml+json http://localhost:8080/authorize

Response

The content-type of the response is specified using the HTTP header accept. The default is application/xacml+json. A non-valid header will result in HTTP 406 Not acceptable.

curl --data @request.json -H content-type:application/xacml+json -H accept:application/xacml+xml http://localhost:8080/authorize

List of authorization decisions

Below are some examples of requests and responses for the four possible decisions, as well as the results returned in certain error conditions:

Decision or error condition	When	HTTP
Permit	The access request has been permitted.	HTTP 200 OK
Deny	The access request has been denied.	HTTP 200 OK
NotApplicable	The policy is not applicable to the access request.	HTTP 200 OK
Indeterminate	There has been an error processing the request.	HTTP 200 OK
Syntax error	Syntactical errors in the request.	HTTP 400 Bad Request
Technical error	For example, when an attribute connector cannot connect to its policy information point.	HTTP 500 Internal Server Error

Authorization decisions

Profile specifications

More information about requests and responses are available in the XACML RESTOpens in a new tab, XACML JSONOpens in a new tab and XACML CoreOpens in a new tab profile specifications, respectively.

note

The deprecated authorization endpoint /asm-pdp/authorize is compatible with JSON Profile of XACML 3.0 Version 1.0 and XACML REST Profile Version 1.0. It is not compatible with JSON Profile of XACML 3.0 Version 1.1 or XACML REST Profile Version 1.1.

Further reading

This section describes some more advanced topics.

Errors

The following describe two very usual errors during requests.

Syntax error

Syntactical errors in the request will result in an HTTP 400 Bad Request.

{
  "code": 400,
  "message": "ERROR_6700_PARSING_ERROR: Error in parsing the XACML Request"
}

Technical error

When a technical error occurs, for example, when an attribute connector cannot connect to its policy information point, an HTTP 500 Internal Server Error will be returned.

{
  "code": 500,
  "message": "Unable to get attribute Attributes.access_subject.subject_type"
}

Correlation

This is an advanced feature related to tracking and monitoring interactions with ADS using the x-xacml-transaction-id header. This optional header serves as a unique identifier for each request and is particularly useful for correlation purposes in audit logging and tracing.

Correlation in audit logging

When audit logging is enabled in the deployment.yaml file (see Logging), the unique transaction ID provided in the x-xacml-transaction-id header is recorded in the audit logs. This enables administrators to trace back specific requests and understand the context and outcome of each, enhancing the ability to monitor and review access decisions and ensuring a robust audit trail.

Correlation in tracing

In the context of tracing, when this feature is active, the transaction ID is attached to the span of a request. This is particularly useful in distributed tracing environments, where understanding the flow and performance of requests across various services and components is critical. By associating a unique transaction ID with each request, it becomes easier to analyze and debug the system's behavior, especially when dealing with complex, multi-service architectures.

note

This applies only when the REST authorization interface is used. The functionality is not implemented for the legacy SOAP authorization interface.