DirX Access Authorization

This chapter deals predominantly with the authorization process of the resources and services that are integral part of the DirX Access product, residing in the DirX Access Server. However, some of its principles and rules apply also on authorization done by DirX Access for third-party resources.

The DXA Server and everything inside it is protected in two ways:

The request-level authorization granularity achieved by the container-level authorization becomes too coarse-grained in certain scenarios. E.g., when performing actions over user OTP credentials record. The record contains all the OTP-authentication relevant data: last generated secret, communication address, and number of consecutive login failures. Let’s have a look at what data shall be administered by what role: the last generated secret being a single-use, shall be managed by the authentication process of DirX Access only; the communication address, if the self-management is enabled, shall be managed by the user themselves; and the number of login consecutive login failures shall be managed by the support desk staff when requested by the user when they accidentally blocked their account.

Described scenario can be achieved by employment of the Java Services API Authorization Layer. This authorization process is performed by DirX Access when accessing any data via the AppRepoService. At the external interfaces, this service is currently used when requesting via the Config RESTful Web Service and SCIM endpoint. Furthermore, to achieve integrity of the results across the whole system, the process is employed also when accessing the AppRepoService from other services running inside the Services container. This means that also the internal public API, the Callout interfaces, is protected by the same means and policies.

The DXA service interfaces represent a part of the DXA’s API. DXA enables to apply authorization policies at this level, that enforce:

The Do use internal authorization parameter of PEPs enables the authorization of DXA internal resources. The internal authorization can take place in the following case:

DirX Access Services container is deployed out-of-the-box with a PEP instance named DirX Access PEP. This PEP intercepts any request received at the external interfaces of the container and enforces their authorization. Although it is theoretically possible to exchange this PEP for a different one, from the maintenance point of view, this is not advised, rather, the configuration parameters of this PEP shall be changed.

The authorization by the physical (deployable) PEP is done based on the parameters of the HTTP request received. Mainly, the requested URL is transformed into the resource part of the authorization request, while the HTTP method is transformed into the action part.

The DXA Server container provides many unrelated services and resources, hence, DirX Access extends the PEP in a way that this independence is reflected. Namely, DXA enables to assign to the main PEP multiple additional PEPs each of which is applicable for a subset of the resources. Each PEP assignment is bound to a context path that determines for what subset of resources the PEP is applied.

With the introduction of Multi-PEP assignments configuration the physical PEP can be subdivided into several virtual PEPs.

By having one default PEP with application of the Multi-PEP assignments, the whole container is always protected, meaning any newly deployed resource is protected from the beginning, while respective sub-resources (applications) can be given their own configuration and policies.

This assignment has also an influence on the resource and policy trees generation. Each resource, when configured, is assigned to certain PEP. Subsequently, when creating authorization policies, each PEP is passed only the policies relevant to its own resources. This in turn means that there is a strict border between what policies are used for what requests. Not only this helps for the performance, but also enables to prevent unintentional misconfigurations. E.g., when configuring the authorization policies for DirX Access Manager – application intended for the administrators‘ access with administrator policies, the whole web application shall be delegated to its own PEP (via the multi-PEP assignment) and any contained resource would then be assigned to this DirX Access Manager-specific PEP. Any changes to any other PEPs then have no effect within this new PEP.

For each request, only one applicable PEP is chosen and is determined according to the following algorithm (see Figure 1):

This algorithm implies, that the assignment rules might generate resource (sub)sets that are not mutually disjunctive. Instead, the choice is deterministic due to their configurable ordering. Furthermore, the PEP assignments might be applicable hierarchically.

The multi-PEP approach has several implications:

The DirX Access Role-Based Access Control (RBAC) policy configuration model enables a simple configuration of the RBAC policies via the configuration interface. Permitted resources and actions are assigned via rule and policy sets to existing roles.

Within this triple - role, action, resource - the resource is the part having some correlation to the applicable PEP. Namely, to each resource a PEP is explicitly assigned. However, the PEP assignment is in place only to resolve an authority to be used in the policies.

The Figure 3 depicts the RBAC policy structure which can be read as follows: a user with role(s) can perform action(s) on resource(s) if condition(s) is met. The action result can be extended by obligation(s). Actions and resources should be provided, obligations and conditions are optional.

The external REST interface provides the standard CRUD operations on all the resources. Internally, these operations are translated into following authorization actions: