PEP Deployment

Overview

When deploying the DirX Access PEPs components, you need to deploy the local PEP configuration and cryptographic material on each application/Web server where resources are to be protected by DirX Access. The configuration of each PEP must be created either manually via the DirX Access Manager or via the import of the configuration through the Config RESTful Web Service. They are again deployed either via DirX Access Manager or via SysActions RESTful Web Service.

DirX Access is shipped with ready-to-use PEPs to secure the following components:

  • Web server or proxy server

  • Application server

  • Application acting as a PEP

Web Server or Proxy Server PEP Deployment Options

As introduced in the sample deployment scenario at the beginning of this chapter, two options are available to you when protecting static content provided by Web servers. You can install a PEP on each Web server in your Web server farm, or you can install PEP instances only on your Web proxy servers.

The proxy model typically reduces administration time, as it requires fewer component installations and minimizes subsequent required maintenance tasks. However, if you choose to follow the proxy protection model, it is recommended that you use at least two proxy servers for redundancy, load balancing and failover. In large-scale environments, more than two Web proxy servers will be necessary.

The following diagram illustrates the two scenarios. Scenario 1 shows a farm of Web servers with PEPs installed directly on them. Scenario 2 shows two proxy servers with PEPs installed that control access to an indefinite number of Web servers.

attachments/att++_++9++_++for++_++112001030
Figure 1. Possible PEP Deployments on Web Servers

Application Server PEP Deployment Options / Applications Acting as PEP

Two approaches can be used when integrating DirX Access policy enforcement point agents into your environment:

  • Declarative: With this approach, the policy enforcement point agents deployed on Web and application servers silently intercept all resource access requests and query the core services for authorization. Any resource definable by its URI (including keyword/value pairs in the query string) can be protected using this approach.

  • Programmatic: Alternatively, applications can call the DirX Access server directly through programmatic means. With this approach, application designers can protect any arbitrary data or elements, such as tables or fields in a database or widgets on a Web page. This approach also provides applications the ability to personalize pages with user information, improving user experience. This is considered in detail in the accompanying DirX Access integration guide.

Mixing the declarative and programmatic approaches within a network can result in a very fine-grained and effective security solution.

The following diagram shows one application server with a DirX Access PEP installed (scenario 1), and another that communicates directly with the PDP through programmatic means (scenario 2).

attachments/att++_++4++_++for++_++112001030
Figure 2. Possible PEP Deployments on Application Servers

Constraints for Apache HTTP Server PEPs

To deploy the DirX Access PEP with the Apache HTTP Server, the following prerequisites apply:

  • Apache HTTP Server version 2.4 must be in use.

  • The Apache HTTP Server module mod_ssl and its underlying SSL/TLS engine OpenSSL version 1.1.0 or higher need to be deployed as prerequisites for running SSL/TLS client authentication between Web browsers and the Apache HTTP Server.

  • Your configured Apache user-Id (httpd.conf) must have read/write access to the logs directory of the Apache HTTP Server installation. The PEPs maintain internal statistics about processed requests using memory-mapped files located in the logs directory of Apache HTTP Server. These files can be avoided by turning off the statistic feature in the dirxaccess.properties file.

Constraints for Servlet-Filter PEPs

  • When deploying a new Web application into a container that contains another Web application protected through the Servlet-Filter PEP, this previously installed Servlet-Filter PEP does not protect the new Web application: the Servlet-Filter PEP needs to be installed for the new Web application.

  • When re-deploying a Web application that is supposed to be protected through a Servlet-Filter PEP, make sure that the Servlet-Filter PEP is still (after re-deployment) configured in the related web.xml. This task may require redeploying the Servlet-Filter PEP.

  • The Servlet-Filter PEP is using the same class loader as the Web application to be protected. We suggest to use Apache Tomcat PEP or Jetty PEP to solve potential dependency incompatibilities.

  1. All subsequent actions can be achieved in either of three ways. Choose the appropriate one and prepare/configure/deploy necessary means:

    1. Direct Application of System Actions and Configuration

      1. It is necessary to prepare the JSON files with appropriate Configuration and System Actions.

    2. Config and SysActions REST Web Services

      1. It is necessary to configure and deploy the Web Services, and prepare the REST requests together with the tool used to execute them (curl, Postman, etc.)

    3. DirX Access Manager

      1. It is necessary to configure and deploy the DirX Access Manager components and its dependencies.

  2. Configure Port Assignments representing ports at the server-side with which the PEP shall communicate and assign them to intended Servers.

  3. Configure and deploy Config REST Web Service and SSO REST Web Service.

    1. TODO: the constant addresses

  4. Configure Multi-Pep assignment (TODO - it ?is? a best practice)

    1. Use “Do exclude from authorization” at the side of the REST Web Service

  5. Configure ServletFilter PEP.

  6. Deploy ServletFilter PEP TODO4

During start-up, DirX Access PEPs consume information about DirX Access Services server host names from their local configuration. The provided server hostname must allow the client to reach the server host. After start-up, DirX Access PEPs consume information about DirX Access Services from remote configuration (through one of the servers reached during start-up). This information also comprises server host name information. The server host names provided via remote configuration objects must also allow the client to reach the server host, which may require that you register the server host names locally (for example, in the hosts file on Windows) or globally (for example, with the DNS server in the Intranet).