PEP for Internet Information Services

This page covers features that are specific to the Policy Enforcement Point written in C (CPEP) for IIS. For general properties describing PEP, please refer to the corresponding section. CPEP is built on a single shared codebase, which serves both IIS and Apache HTTP Server. However, each architecture has its own set of specific features and configurations. For information about Apache HTTP Server-specific features, please refer to the dedicated Apache HTTP Server CPEP page.

Installation

CPEP is distributed as a zip archive, where there is an installation guide (installation.txt). The ZIP archive includes an installation.txt file that contains detailed instructions for the installation process. The content of the file is reproduced here for convenience and has been supplemented with additional illustrations and visual aids to make the process easier to follow. The archive also includes a configuration file (dirxaccess.properties), CPEP binary (DirXAccess_IIS_PEP.dll), OpenSSL libraries (libcrypto-3-x64.dll and libssl-3-x64 and boost libraries (boost_context-<vc-version>-mt-x64-<boost-version>.dll and boost_url-<vc-version>-mt-x64-<boost-version>.dll), where <vc-version> and <boost-version> can differ depending on the version of the CPEP.

For a successful installation of this extension, following actions are necessary:

  1. Stop the IIS service.

  2. Copy the content of the “windows64\IIS\bin” to the desired installation directory on the Windows Server.

    If the OpenSSL or Boost libraries files are already present in your system or the IIS folders, you do not need to copy them again. Otherwise, ensure these files are copied to the root IIS folder or the same directory as the main DLL.

    The dirxaccess.properties configuration file must always be stored in the same directory as the main module DLL.

  3. Add following configuration to the “dirxaccess.properties” file:

    • {client_id}

      • The configuration identifier of the “IIS” PEP type in the DirX Access configuration.

    • {primary_dirx_access_server_hostname}

      • The hostname of the DirX Access Server instance to fetch the PEP remote configuration for the first time, e.g my-server1.my-company.example.

    • {primary_dirx_access_server_port}

      • The port of the DirX Access Server instance to fetch the PEP remote configuration for the first time, e.g. 11111.

    • {primary_dirx_access_server_port_ssl}

      • The SSL port of the DirX Access Server instance to fetch the PEP remote configuration for the first time, e.g. 11112.

    • {secondary_dirx_access_server_hostname}

      • The secondary hostname of the DirX Access Server instance to fetch the PEP remote configuration, e.g my-server2.my-company.example.

    • {secondary_dirx_access_server_port}

      • The secondary port of the DirX Access Server instance to fetch the PEP remote configuration, e.g. 12111.
        {secondary_dirx_access_server_port_ssl}

      • The secondary SSL port of the DirX Access Server instance to fetch the PEP remote configuration, e.g. 12112.

    • A description of all configuration parameters is the same as for the Apache HTTP PEP and can be found in the Configuration section.

  4. Generate the sec-comm.client.p12 keystore to enable secure communication between the PEP and DirX Access Server instances.a]

    1. Find the dxaCryptoGenerateKeystoreSecCommClient.json template within the DirX Access <installation_directory>\Services\templates\instance\etc\templates\sysactions
      b]

    2. Recall the issuer of the “Keystore Crypto Container” of the respective server port assignment of the {primary_dirx_access_server_port_ssl} and {secondary_dirx_access_server_port_ssl} SSL port of the server.A description of Port Assignment configuration can be found at:

      1. Port Assignment

      2. Port Assignments

    3. Use the same issuer in the dxaCryptoGenerateKeystoreSecCommClient.json template.

    4. Choose and remember the keystore password of the dxaCryptoGenerateKeystoreSecCommClient.json template. The same password will be applied at the step 5).

    5. You can choose from two options:

      1. (Preferred) Apply the template to the <installation_directory>\Services\instances\<instance_name>\startup directory of the running instance and restart the instance (sec-comm.client.p12
        will be located in c:/Users/Administrator/Downloads)

      2. Go to the DirX Access Manager -> System actions -> Keystore management -> Generate keystore and apply the configuration of the template here.

  5. Copy the generated sec-comm.client.p12 keystore to the desired location

    1. open dirxaccess.properties file and set both {client.keystore.filename} and {sec-comm.client_keystore_password} accordingly.

  6. Configure IIS to use the native module:

    1. Open the IIS Manager.

    2. In IIS Manager, navigate to the root webpage and go to the Modules section in IIS Manager.

    3. Right click to module list and select Configure Native Modules…

    4. Select Register…

    5. Input a name for the module.

    6. Select the correct path to DirXAccessDLL_IIS_PEP.dll

    7. Press OK

    8. Press OK

      image.png
      Figure 1. Registration of the module in IIS manager

  7. If you use output caching please follow instructions here: HTTP Caching.

  8. Install Microsoft Visual C++ RedistributableIf you don’t have the Microsoft Visual C++ Redistributable installed:
    Download the latest supported Visual C++ Redistributable package from the Microsoft website.
    Microsoft Visual C++ Redistributable latest supported downloads
    Run the installer and follow the on-screen instructions to complete the installation.

  9. Start the IIS service.

Configuration

Same configuration parameters described here: Configuration. apply, but instead of the dirxaccess.conf file, they are specified in the dirxaccess.properties file. You can also configure logging. (please see Logging for more information). )

Handling POST Requests for Static Files in IIS Version 7 and Above

Microsoft Internet Information Services Version 7 and above do not allow HTTP request by sending the POST method to a page that is configured to be handled by the StaticFile handler. Attempting this method results to the message “405 Method Not Allowed - The request is for static content and contains an HTTP verb other than GET or HEAD”. Some applications in DirX Access use the POST method (Authentication Application, SAML, OAuth) to redirect to the target URL. To work around this problem, set the target URL to a page that is configured to be handled by a handler other than the StaticFile handler (for example, the ASPClassic handler) or assign the IsapiModule instead of the StaticFileModule to the extension for the static file content.

HTTP Caching

The HTTP Caching feature is used for caching responses for static or semi-static[1] resources via the httpCacheModule. IIS supports two modes of caching:

  1. Kernel Mode Caching:

    • This provides caching at the operating system (kernel) level. Requests are intercepted and served directly from the cache without being forwarded to the IIS Worker Process. This makes it extremely fast but limited in configurability.

  2. User Mode Caching:

    • This provides caching at the application (user) level. Here, the IIS Worker Process handles the caching and allows more advanced configuration. Responses can be cached based on query strings or headers, such as VaryByQueryString or VaryByHeader.

Key Considerations When Using DirXAccess CPEP with httpCacheModule

When combining DirXAccess CPEP with the httpCacheModule, special attention must be given to avoid critical security issues. Misconfigurations can allow caching to bypass the CPEP module, potentially serving pages to users who should not have access.

Critical Recommendations:

  • Disable Caching for Protected Resources:

    • Both Kernel Mode Caching and User Mode Caching should be disabled for any resources protected by CPEP.

  • Avoid Relying on Varying by Headers like Cookie:

    • While it might seem feasible to use user-mode caching with a VaryByHeader configuration for Cookie, this approach has significant risks. Consider the following scenario:

      1. A user logs in, and the server creates a new session token <TokenA>.

      2. The user accesses a protected resource, e.g., webpage/<some_protected_resource>, with Cookie :<TokenA>. The response for this resource is stored in the cache.

      3. The user logs out, invalidating <TokenA>.

      4. The user (or an attacker) reuses Cookie : <TokenA> to access webpage/<some_protected_resource>.

      5. Since the response is cached, the resource is returned directly from the cache without verifying the token’s validity, exposing protected content.

Architecture

Same as Apache HTTP Server PEP Architecture.

Logging

Logging can be directed to two possible outputs in DirX Access:

  1. A log file specified by the client.log.file configuration parameter in the dirxaccess.properties file.

  2. The Windows Event Viewer, if no file is specified.

Additionally, the logging level can be configured by specifying a number between 0 and 7 for client.log.level parameter in the dirxaccess.properties file. Each number corresponds to a different logging level: 7: Debug, 6: Info, 5: Notice, 4: Warning, 3: Error, 2: Critical, 1: Alert, 0: Emergency

Reintegration of an unavailable server

See Reintegration of an unavailable server.

Performance

See PEP for IIS - Performance

1. You can understand a semi-static resource as a for example resource that is generated based on the database but the database is changed sporadically.