Initial Configuration

After a successful installation with no Direct Application of System Actions and Configuration, DirX Access Server is started with no published web applications or endpoints. At this point, the Direct Application of System Actions and Configuration shall be used.

For the deployment of the servers in the production phase, typically the target configuration has already been tested in the testing environment. This configuration can be exported, the parameters that differ between the testing and production environment can be changed, and the resulting configuration file applied during the initial start up of the production server. This way, the server runs with its target configuration right from the start, which increases the overall security and minimizes the possibilities of misconfiguration.

Configurability-oriented Approaches

For the servers the configuration of which is to be changed, such as testing, integration and some production servers, the ability to be configured in a more dynamic way has to be achieved. According to this feature, the administrator can choose one of three fundamentally different approaches:

  • Business-service-only Server

  • Scripted-configurable Server

  • UI-configurable Server

These approaches have to be combined with authentication mechanisms to achieve appropriate access control.

Business-service-only Server

This approach minimizes the interfaces of the DirX Access Server to only the business-oriented ones.In this way, the security attack surface is minimized.

The configurability of the DXA is also minimized, however, still can be achieved either via the Direct Application feature, or via another DXA Server from the same cluster that publishes configuration interfaces.

Scripted-configurable Server

Comparing to the Business-service-only Server, this approach additionally creates and exposes:

  • SysActions RESTful Web Service

  • Configuration RESTful Web Service

The combination of these exposed interfaces enables to further deploy/configure any feature and component of DXA via the REST interfaces, in a scripted or manual way.

The Port Assignments management enables to deploy the aforementioned Web Services separately from the business-oriented ones. This way, they can be protected by additional means, such as port-specific firewall filtering.

To achieve the Scripted-configurable Server, following templates have to be used in given order (i.e., they might need to be renamed):

UI-configurable Server

To enable management of the Dirx Access Server via a user interface - the DirX Access Manager web application - following components have to be deployed and configured:

  • SysActions RESTful Web Service

  • Configuration RESTful Web Service

  • SPA Core Application

  • DirX Access Manager Plugin Application

The combination of these exposed interfaces enables to further deploy/configure any feature and component of DXA via

  • the REST interfaces, in a scripted or manual way,

  • the UI (DirX Access Manager) in a manual way.

The Port Assignments management enables to deploy the aforementioned Web Services and applications separately from the business-oriented ones. This way, they can be protected by additional means, such as port-specific firewall filtering.

The SPA Core Application and DirX Access Manager Plugin Application are a static single-page applications, i.e., they can be deployed in any Web Server and can communicate to the RESTful Web Services remotely. By default, they are deployed locally in the DirX Access Container.

To achieve the Scripted-configurable Server, following templates have to be used in given order (i.e., they might need to be renamed):

Initial Authentication Mechanism

DirX Access Container as a whole (and therefore each deployed web application and endpoint) is protected by default authorization policies, giving the access only to the administrators. The authentication mechanism has to be chosen and configured in order to enable to authenticate the users and apply the authorization policies.

DirX Access templates provide different authentication mechanisms suitable for different security environments.

Basic Authentication Mechanism

The Basic Authentication shall be used in production only in very limited and well-advocated use cases. On the other hand, its ease-of-use and simple configurability makes it a perfect starting point for demonstration and testing scenarios.

This mechanism can be used also in scriptable configuration scenarios, where the scripted requests are enriched with credentials in the Basic Authorization HTTP header.

To configure the Basic Authentication Mechanism, following templates have to be used in given order (i.e., they might need to be renamed):

Authentication Application Authentication Mechanism

The Authentication Application Authentication Mechanism is a production-ready approach to the initial user authentication. It consists of the Authentication Application providing choices of different authentication methods to the end users (the templates contain only the Basic authentication methods, others have to be configured according to available authentication means for given project).

The result of the interaction with Authentication application is issuance of a session cookie facilitating the single sign-on (SSO) feature, within the area of a single domain.

To configure the Authentication Application Authentication Mechanism, following templates have to be used in given order (i.e., they might need to be renamed):

SSO RESTful Web Service Authentication Mechanism

TODO

JWT Authentication Mechanism

TODO

Self-issued JWT Authentication Mechanism

TODO

Initial Keystores Configuration

The installation process generates a {installation_folder}/Services/instances/{instance}/startup/sysactions/dxaDefault1SysActionCryptoGenerateSystemTrust.json file. Upon the start-up, this file autogenerates a keystore with Certification Authority that can be used for generating additional necessary keystores (typically the ones used for internal purposes, that do not require a public Certification Authority).

The Keystores can be managed fully according to the will of the administrator - for the production environment, it is a good idea to have an external Certification Authority and keystore generation tool. However, to quickly fulfill the essential tasks, the auto-generated Certification Authority can be utilized to provide necessary crypto-material.

Web Server Keystore

The PortAssignment configuration objects declare open ports at which web applications are published. The installer enables to declare a number of port protected by TLS, which is translated into corresponding PortAssignment configuration object. At the moment, where there is a necessity to deploy any web application at this port, we have to supply appropriate keystore. This can be achieved using following System Actions template file:

JWT Signing and Encryption

For more information, please, see Session Management.