Access Control On Virtual Data Views

In a virtual data view, Directory Proxy Server exposes virtual data. Directory Proxy Server is therefore responsible for controlling who can access that data, and what parts of the data can be accessed. To control access to virtual data, you can define virtual ACIs. When Directory Proxy Server receives a request on a virtual data view, it uses the virtual ACIs, and any authentication information provided by the user, to allow or deny access to the information that is requested.

This section describes the syntax and architecture of virtual ACIs. For information about configuring virtual ACIs, see Defining Access Control on Virtual Data Views in Oracle Directory Server Enterprise Edition Administration Guide.

Virtual ACI Definition

Virtual ACIs are defined by using the dpsaci operational attribute. The dpsaci attribute is multi-valued. This means that several ACIs can be defined for the same portion of a directory.

Directory Proxy Server is responsible for the management of the dpsaci attribute. This attribute can be configured along with the physical data but it is not stored with the data. When the dpsaci attribute is included in a request, Directory Proxy Server extracts it from the request and manages it in a dedicated ACI repository, through its own ACI data view.

A modify request that targets a virtual data view and contains the dpsaci attribute is effectively split into two requests by Directory Proxy Server. The first request handles only the virtual data, and the second request handles the virtual ACI.

Global ACIs

Global ACIs are defined in the entry cn=data-source-name,cn=virtual access controls. These ACIs are evaluated by an ACI engine to deny or allow requests from a connection handler using that ACI pool. Global ACIs are required to allow or deny application administrators to access certain data. These application administrators can then provide more finely-grained access control to users, by placing ACIs directly in the data.

Only the proxy manager can create a pool of ACIs and manage ACIs directly through the ACI data view. Application administrators cannot manage ACIs directly through the ACI data view, even if they have the right to add entries. Application managers can only manage ACIs directly through the data.

ACIs that are defined in the data itself, are evaluated by Directory Proxy Server. These ACIs are entries in the pool of ACIs defined by the proxy manager, that is they are child entries of the entry cn=data-source-name,cn=virtual access controls.

ACIs have a performance impact. Therefore, if you use ACIs within the data itself, keep to a minimum the number of rules in the global ACIs, because these ACIs are evaluated every time the subtree is accessed.

Virtual ACI Syntax

The dpsaci attribute resembles the Directory Server aci attribute in syntax and behavior. For a description of Directory Server ACI syntax, see How Directory Server Provides Access Control.

The following list describes the differences between virtual ACIs and Directory Server ACIs.

• Target keywords. Only the target, targetAttr and targetscope keywords are supported.

• Permission keywords. The All access write does not permit selfwrite operations.

• Bind rule subject. For performance reasons, virtual ACIs do not support the ldap:///suffix??sub?(filter) as a value for the userdn keyword.

• Bind rule context. Virtual ACIs do not support SASL authentication. In addition, the ip keyword does not support subnet masks.

Virtual ACI Storage and Access

Virtual ACIs are stored centrally, in an LDIF file or in an LDAP directory. When you create a Directory Proxy Server instance, the virtual ACIs are stored in the LDIF file instance-path /config/access_controls.ldif by default. You can change the location of the virtual ACIs, particularly if you need to share ACIs across multiple proxy servers. For information about how to change the location of virtual ACIs, see To Define a New ACI Storage Repository in Oracle Directory Server Enterprise Edition Administration Guide.

The ACI repository is accessed through an LDAP or LDIF data view, depending on the type of repository. By default, the access control data view is an LDIF data view named virtual access controls. The view base exposed by the access control data view must exist in the ACI repository.

The ACI repository contains one or more pools of ACIs. An ACI pool is defined by an LDAP entry of the type aciSource, directly below the view base of the data view. The ACI pool is a subtree of entries. It can contain access controls, and can be the parent entry of other entries containing ACIs.

Virtual ACI Application

Virtual ACIs are applied per connection handler. The name of the ACI pool to be used is defined as the aci-source property of the connection handler. Virtual access controls are not evaluated if you bind as the Proxy Manager.