System Overview

DirX Access directly addresses several requirements common to current privacy legislations such as the U.S. Sarbanes-Oxley Act (SOX). As a complete access management system, DirX Access not only complies with these privacy regulations itself in its own architecture and implementation, but also makes your network infrastructure, including the resources and Web services you have already deployed, compliant with many of the same standards.

The use of role-based access control in DirX Access solves many of the problems inherent in creating and managing systems with tight security and stringent privacy policies. Because access to information sources and applications is provided to business roles that are in turn associated with users, the likelihood of individual users acquiring access to protected resources is reduced.

In addition, when a user switches role in the organization, his or her access rights change automatically. This eliminates the possibility of a situation where a user with access to sensitive personal information such as medical records moves to a new position in the organization and incorrectly maintains those access rights simply due to administrative oversight.

DirX Access in its default configuration does not manage any user data. As seen from Figure 1, for the initial user authentication, it needs to be connected to a user repository. Typically, this repository (e.g., corporate user directory) must exist independently on the deployment of DirX Access which concludes that by default DirX Access does not yield additional requirements according to the GDPR. However, certain configurations (such as user-aware risk-based authentication) might require user-related data to be stored. In such case, consult appropriate documentation sections for more information.

The multi-factor authentication is highly favorable (if not required) by the majority of the most important regulations (e.g., SOX, NIST Digital Identity Guidelines, etc.). DirX Access enables employing the strong multi-factor authentication out-of-the-box by combining the building blocks represented by strong authentication methods, such as PKI, FIDO, OTP, etc., into a configurable sequence.

DirX Access enforces passwords across the organization. It removes the need for each system component to request and validate passwords on its own, centralizing authentication and password management in one unit for tighter control. Furthermore, DirX Access allows the typical user name and password model to be refused for selected resources in favor of even more secure methods of authentication, such as X.509 certificates.

Perhaps the most crucial aspect of privacy regulation conformance, however, is the capability to execute complete end-to-end auditing on all system access events. It is not enough to merely deploy a system that should be secure, no matter how well defined; a requirement for complete confidence in an access management system is a way to confirm on an on-going basis that the security measures in place are not being compromised. With the auditing capabilities offered by DirX Access, administrators can review exactly who had access to what applications, and when, ensuring accountability for all users and resources in the system.

DirX Access allows administrators to customize security levels in a variety of ways, via RBA conditions, authorization conditions and rules, and the optional use of SSL/TLS encryption for internal communications to maintain the integrity of all data passed along the line. For more information on evaluating the security needs of your organization and designing your DirX Access deployment, see the chapter “System Deployment” in the “Administration Guide”.

DirX Access delivers its core authorization, authentication and identity federation functionality using the components that are described in the following sections.

DirX Access deployments can be broadly separated into the following tiers:

The following figure presents the DirX Access architecture from a high-level component standpoint:

The DirX Access Cache Server component provides the distributed cache and persistence to their clients embedded in DirX Access Servers.

The principal architectural elements in an authorization system are the policy enforcement points (PEP) and policy decision points (PDP). These elements are further augmented by a policy management authority (PMA).

Typically, interactions between these components begin with the PEP, which intercepts a request for a protected resource and passes the request to the PDP. The PDP pulls policy information from the PMA, which may use a directory server or other information repository to persist authorization policies. The PDP validates the information provided by the PEP against the policies provided by the PMA to determine whether the user is authorized to access the requested resource. It returns its decision to the PEP, which enforces the decision by providing or refusing access.

The following sections describe the way these conceptual architectural components are supported in DirX Access.

Role-based access control (RBAC) represents a specific instance of an authorization model that makes use of an indirection between users and resources through the RBAC-defined concepts of roles and permissions.

The underlying principle of RBAC systems is that business roles tend to be more stable and change less often than the users fulfilling those functions. Permissions are therefore assigned to roles, and roles are assigned to users as required.

The following figure illustrates the relationships between permissions, users, and roles.

RBAC authorization policy is translated by DirX Access into XACML for processing in the PDP as well as caching as Java objects.

This authorization model is constrained according the XACML profile for RBAC; all policies that can be expressed for the RBAC model belong to this dedicated profile, as illustrated in the following figure:

RBAC authorization policy information can be managed through the administration Web application provided by DirX Access as well as through the provisioning Web service:

Note that the DirX Access restricts policy management to authorized administrators to prevent tampering with the system access control policies, and maintains the uniqueness of policy identifiers to prevent conflicts.

Permissions are created on the DirX Access Manager Policies page. The Roles page is used to create roles, and to assign existing permissions to roles. Roles can be assigned to users either on the Roles page or the Users page.

DirX Access supports role hierarchies, which define seniority relations between roles. Senior roles in the hierarchy may inherit permissions from junior roles.

For example, in the role hierarchy pictured below, the Production Engineers may be authorized to access software source code repositories for their respective projects, while the quality engineers may be authorized to access bug databases for their respective projects. The project leads may be able to access both the code repository and the bug database, but only within their respective projects. The director, however, may access either system for either project.

To ensure the tightest possible security, it is recommended that you follow the principle of least privilege. Assign each role (and therefore the user or users assigned to that role) only the minimum access rights required to carry out its business objectives.

For example, if the vice-president of the Sales department never takes orders over the telephone, and does not know how to use the Web-based application used by the order-takers, the principle of least privilege suggests that inheritance from junior roles would not be appropriate.

The image below shows the role configuration page in DirX Access Manager.

Role exclusion, or separation of duties, is a way of avoiding the conflicts of interest that may arise if users are assigned two incompatible roles. When two roles are excluded from each other, any user with one of the roles assigned cannot have the other role assigned at the same time. For example, a user authorized to buy a certain commodity is not allowed to sell the same commodity.

Separation of duty relations between roles reduce the number of permissions that can be made available to a user by placing constraints on which roles can be assigned to which users. Each role has an associated set of other excluded roles; whenever an administrator attempts to assign a role to a user who already has one or more of the excluded roles assigned, DirX Access Manager reports the conflict and blocks the new user assignment.

DirX Access implements extension of the RBAC authorization model called Role Enablement Authority, or REA, that supports multi-dimensional and dynamic role assignments. The REA concept is described in the section “Role Enablement Authorities” in the “Administration Guide”.

Each PDP provides a switch that enables the multiple decision profile. When activated, any request message can be composed of semantically multiple requests evaluated according to the profile. As this profile is internally processed for the standard version 3.0 only, the XACML response will be always in version 3.0, regardless to the request version.

While the DirX Access-internal clients of PDPs do not make use of multiple decisions, the external clients are free to use them from any API. For more information, see the profile.

Administrators can assign a ranking to authentication methods using the DirX Access Manager. This ranking, provided by assurance levels, indicates how secure the authentication methods are relative to each other on a numeric scale. For example, the password authentication method is relatively weak, and may be assigned a weight of 1, while an X.509 certificate method may be seen as stronger, and therefore assigned a higher weight of 5.

The PDP can use assurance levels as conditions for authorization. For example, a critical resource may be assigned a policy with an assurance level condition of 10, requiring that users be authenticated using only the most secure methods in order to achieve access. As a result, an authenticated user whose role includes access to the critical resource can still be denied if the method used to initially authenticate that user was not secure enough to meet the desired assurance level condition.

As an alternative to weighted assurance levels, a condition associated with an authorization policy can also specify exactly which authentication method or methods must be used in order to achieve access.

Identity federation supports organizations in consuming identities maintained by others. Identity federation scenarios recognize service, identity and proxying identity providers:

In identity federation scenarios, identity data comes in the form of transient authentication statements that are transferred in an interoperable and secure way. These authentication statements are also known as security tokens and come in the form of SAML assertions in DirX Access.

The identity federation system in DirX Access is based on DirX Access federation endpoints and DirX Access Services:

DirX Access administration is performed through DirX Access Manager, a single-page web application utilizing the SysActions and Configuration RESTful Web Services. Administrators can use DirX Access Manager to perform a variety of tasks, such as:

For an introduction to DirX Access Manager, see the chapter “Administrative Tools”. For detailed information on performing the tasks listed above, please see the chapter “Administrative Tasks”. The remainder of this section provides an overview of the delegation model in administration and the administrative roles in DirX Access.

Business roles are the key to deploying and maintaining DirX Access effectively. A business role represents a definable job or business function, such as HR staff, sales representative, accounting staff, and so on. Each role has one or more associated access policies, which are aggregations of permissions that allow access to protected resources necessary to accomplish a business function, such as Web pages, Servlets, bean methods, etc.

Once a role is created in the system, the Role Administrator must assign the role to a user or a group. The permissions granted to the role allow the assigned user or group to access resources, and therefore to perform the job responsibilities represented by the role.

The following figure illustrates the relationship between users, groups, roles and resources:

For example, a "Payroll Clerk" role may have an associated policy that gives access to the corporate payroll system. Once this role is assigned to a new employee in the accounting department, that employee becomes able to access that payroll system.

Auditing is the process of examining and reviewing the recorded actions taken by system users. Auditing is essential for a security system to determine the effectiveness of existing controls, to monitor for system misuse or abuse by users, to verify compliance with current security policies, to validate that documented procedures are followed, and to detect anomalies or intrusions. Effective auditing requires that appropriate data is recorded in the first place, and that the recorded data be periodically reviewed by authorized personnel. Auditing primarily serves compliance purposes.

In order to provide complete accountability for individual users, the auditing system must be able to identify each authenticated user correctly. This is the primary distinguishing feature of user audit data in comparison to system logs. Log data captured by DirX Access, by contrast, is typically generated by system processes and threads to report significant events or information about the internal state of the system or its components. Logging primarily serves debugging purposes.

For example, when a remote server does not respond, the log message may indicate the failure to reach the server, but will not indicate the user who initiated the connection request. Log data is not directly traceable to specific users or their actions.

By contrast, audit data generated by the DirX Access audit service corresponds directly to the actions taken by identifiable and authenticated users. Actions recorded for each user include:

Taken together, all the audit information gathered is sufficient for any later investigation. In a sense, audit data is the complete recorded history of a system user.

Once the audit data is recorded, it must be reviewed on a regular basis in order to maintain effective operational security. Reviewers must watch for events that signify undesired intrusions or misuse of the system and its user privileges, and must plan ways to strengthen the active security measures should it become necessary.

The DirX Access auditing subsystem allows a variety of auditing sinks to be integrated with DirX Access through an externalization interface that is used to drop audit events and that can be implemented by (third-party) auditing sinks.

There is also a default implementation of this externalization interface that is provided off-the-shelf. This default implementation makes use of Log4J and can be configured through the standard Log4J means. Any Log4J appender can be used to handle DirX Access audit data; for example:

Out-of-the-box DirX Access employs a file-based appender that produces audit files called “audit.log”. By modifying the standard Log4J configuration file log4j.properties, (section “AUDIT APPENDER”) arbitrary Log4J appenders can be deployed for DirX Access audit data. The DirX Access Integration Guide provides details on how to integrate third-party auditing sinks.