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:

  • Audit administrator - this role has full rights for a tenant and can especially create public reports and Dashboard components that are visible for every common auditor.

  • Auditor - this role is a common tenant auditor with access to all views of DirX Audit Manager. An Auditor can use public Dashboard components and reports and create private versions from these public items using copy and paste. 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. 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.

  • VIP auditor - this role is mapped to a group during the authentication configuration, but its access control implementation requires an additional deployed File PEP or DirX Access PEP using authorization policies. A possible scenario is to restrict access to audit events based on the Identification - Sensitivity attribute value. For example, VIP auditors can access all audit events, but other users can access only those events that do not have the attribute value of "high". A sample XACML-based policy for such a scenario can be found on the installation media in /Additions/Data/SamplePolicies/high_sensitivity_policy.xml.

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 an 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.

The following authorization PEP implementations are currently provided:

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

  • File PEP - PEP based on policy files configured and deployed with DirX Audit.

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

All PEPs 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, File PEP and DirX Access PEP.

PEP Processing

Both the File PEP and the DirX Access PEP assume 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 both the File PEP and 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. When you configure the File PEP, you must create XACML policy files on your own.

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.