Authorization

DirX Audit provides authorization on several levels. It supports several application roles and it also allows configuring an authorization Policy Enforcement Point (PEP) to intersect reading of audit messages.

This chapter provides information on how to manage authorization. It describes how to:

  • Manage application roles

  • Manage authorization policy enforcement points (PEPs)

Managing Application Roles

DirX Audit supports the following application roles in DirX Audit Manager and REST services:

  • Audit administrator – this role has full rights for an assigned tenant and full access to all DirX Audit Manager features. Audit administrators can especially create public views that are visible for every common auditor.

  • Auditor – this role is a common tenant auditor with access to all DirX Audit Manager features. An Auditor can use public or product views and create private versions from these views that can be further modified. Private views and reports are only visible for the auditor who created them.

  • Restricted auditor – this auditor role has restricted access rights. A restricted auditor can only run and schedule some reports, but cannot use Audit Analysis and History views in DirX Audit Manager. In the Report view, a restricted auditor can see only reports that are tagged as Restricted. These reports typically require a parameter such as the organization or organizational unit. It is taken from the attributes of the auditor, which are retrieved during authentication from the associated LDAP directory or from the ID token provided by the OIDC provider (depending on the authentication method defined in the configuration for the tenant). The value of this parameter is used to further restrict the result of the SQL query, so that the report shows only audit events or history entries related to the auditor’s organization or organizational unit. Such restricted reports will fail with an error if those required parameters are not provided by the authentication process.

DirX Audit supports the following application roles in DirX Audit Manager Classic:

  • Audit administrator – this role has full rights for an assigned tenant and can especially create public Audit Analysis filters and Dashboard components that are visible for every common auditor.

  • Auditor – this role is a common tenant auditor with access to all features of DirX Audit Manager Classic. An Auditor can use public Dashboard components and filters and create private versions from these public items that can be further modified. Private components and reports are only visible for the auditor who created them.

  • Restricted auditor – this auditor role has restricted access rights. A restricted auditor can only run and schedule some reports, but cannot use Dashboard, Audit Analysis, and History views in DirX Audit Manager Classic. In the Report view, a restricted auditor can see only reports that are tagged as Restricted. These reports typically require a parameter such as the organization or organizational unit. It is taken from the attributes of the auditor, which are retrieved during authentication from the associated LDAP directory. The value of this parameter is used to further restrict the result of the SQL query, so that the report shows only audit events or history entries related to the auditor’s organization or organizational unit.

For details on report definitions, see the chapter “Customizing Reports” in the DirX Audit Customization Guide. Especially note that the tag Restricted corresponds to the key report.tag.restricted. For example, see the report definition EvnImportedUsersApplication_restricted and its SQL query defined with the EvnImportedUsersApplication report.

Managing Authorization PEPs

Authorization PEPs are responsible for user authorization to read audit events stored in the DirX Audit Database.

Authorization is applied only in Audit analysis view in Audit Manager Classic and in legacy events report and context events reports configured in Audit Manager Classic. All other views in Audit Manager Classic, Audit Manager and REST API do not apply authorization described in this chapter.

The following authorization PEP implementations are currently provided:

  • Empty PEP – no authorization is enforced. All users can access all audit events.

  • DirX Access PEP – PEP connected to DirX Access Server and based on policies configured there.

It can be configured with the Tenant Configuration Wizard. See “Authorization Configuration” in “Using the Configuration Wizard for the Tenant Configuration” in “Configuring DirX Audit” in the DirX Audit Installation Guide for details on configuring Empty PEP and DirX Access PEP.

PEP Processing

The DirX Access PEP assumes a policy decision point (PDP), which implements XACML 2.0 requests and responses (urn:oasis:names:tc:xacml:2.0:context:schema:os).

Before a query request is performed, the PEP sends a XACML request to the PDP. The request contains all known subject attributes including the group memberships, the resource and the action.

If the response contains a decision “deny”, a security exception is returned, which causes DirX Audit not to perform any query.

If the response contains a decision “permit”, the PEP investigates the response for obligations. If there is no obligation, DirX Audit can perform the query unchanged.

If the XACML response contains one or more obligation elements, they are considered to represent query constraints. Query constraints are expected to be the values of the XML sub-elements <AttributeAssignment> with AttributeId="urn:com:siemens:dxt:xacml:extendQuery:and". The PEP extends the query with these obligations by adding each query constraint as an additional condition in the "AND" conjunction to the original query.

DirX Audit then performs the changed query and presents the result without any further involvement of the PEP.

For further details on the XACML request, the policies and the obligations, see the following sections.

XACML Context Request

The PEP sends a XACML 2.0 context request according the schema urn:oasis:names:tc:xacml:2.0:context:schema:os. It contains a <Subject>, a <Resource> and an <Action> element.

The <Subject> contains a list of <Attribute> elements containing the known attributes of the authenticated user. The PEP uses the following format for the AttributeIds:

  • urn:oasis:names:tc:xacml:1.0:subject:subject-id: contains the distinguished name (DN) of the user.

  • urn:oasis:names:tc:xacml:2.0:subject:role: contains the group DNs of which the LDAP user is a member.

  • urn:com:dirxcloud:audit:xacml:application-role: contains the DirX Audit application role (for example, Auditor or Audit admininstrator).

  • All other LDAP AttributeIDs start with the prefix "urn:siemens:com:dirxaudit:ldap:" followed by the LDAP attribute name. The following example denotes the "ou" attribute: urn:siemens:com:dirxaudit:ldap:ou.

The <Resource> element simply contains an <Attribute> element with
AttributeId=” urn:oasis:names:tc:xacml:1.0:resource:resource-id”
and the database name as content value of the element <AttributeValue>.

The <Action> element contains an <Attribute> element with
AttributeId="urn:oasis:names:tc:xacml:1.0:action:action-id"
and "query" as content value of the element <AttributeValue>.

Note that all attribute values are considered to be strings.

For a sample of a context request, see the Additions/Data/SamplePolicies folder on the product installation media.

Access Policies with Obligations

The access policies used for the DirX Access PEP are supposed to adhere to the XACML 2.0 schema "urn:oasis:names:tc:xacml:2.0:policy:schema:os". When deployed with DirX Access, you can edit the policies using the DirX Access Manager by navigating to Policies → ABAC policies.

For policy sample files, see the Additions/Data/SamplePolicies folder on the product installation media.

The <Obligations> sub-element of an access policy is particularly important. It is optional and contains several <Obligation> sub-elements. The DirX Audit PEPs evaluate them only on "permit" decisions.

In this case, they assume sub-elements <AttributeAssignment> with an
AttributeId="urn:com:siemens:dxt:xacml:extendQuery:and"
and the content value as the query constraint. It is in XML format and adheres to the schema
"http://dxt.siemens.com/manager/configuration" and is the same format that DirX Audit Manager uses internally to represent its queries. Since this query constraint is the content of an XML element, the special XML markup characters must be escaped.