> For the complete documentation index, see [llms.txt](https://experience-digital-transform.gitbook.io/experience-digital-transformation/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://experience-digital-transform.gitbook.io/experience-digital-transformation/information-mediator/configure-the-information-mediator-before-approval.md).

# Configure the Information Mediator Before Approval

After the Security Server is installed, the repository uses a first configuration phase for work that can be completed before the approval-dependent final stage.

Run:

```bash
ansible-playbook configure-step1.yml
```

The playbook invokes the `configure_pre_approval` role.

## What this phase does

The repository describes this role as the **pre-approval configuration** phase. Its responsibilities include initialization, certificate creation/signing/import, certificate registration, member configuration, and subsystem/service setup.

The workflow is designed to be idempotent where possible: it checks existing Security Server state before creating keys, certificates, clients, or service descriptions.

## 1. Create a temporary API key

The role first creates an API key for Security Server API access.

The shared `create_api_key` role:

* waits for the Security Server pod;
* checks that the local Security Server UI/API is reachable;
* creates an API key using Security Server credentials;
* grants the standard Security Server API roles, including service administration;
* builds the authentication header used by subsequent API calls.

The role deletes the temporary API key when configuration finishes.

## 2. Import the configuration anchor and initialize the server

The role checks the Security Server initialization status.

If needed, it:

* decodes the configured Central Server configuration anchor;
* imports the anchor into the Security Server;
* initializes the Security Server with the configured member class, member code, Security Server code, and software-token PIN.

The configuration anchor is required. The role stops if it is unavailable.

## 3. Log in to the software token

The role retrieves the Security Server token, determines whether it is already logged in, and logs it in using the configured token PIN when necessary.

Configuration stops if token login fails.

## 4. Prepare signing and authentication certificates

The role inspects the token for existing signing and authentication certificates.

If the required material is missing, it creates new keys and certificate-signing requests.

For the signing key, the request is associated with the member identity. For the authentication key, the request is associated with the Security Server host identity.

The repository's current automation sends the generated CSRs to the configured **test CA** signing endpoint and imports the returned certificates into the Security Server.

{% hint style="warning" %}
This behavior is specific to the checked-in automation and environment configuration. Do not generalize it into a requirement for every Information Mediator deployment.
{% endhint %}

## 5. Configure management-service integration

The pre-approval role also contains automation for the management-service relationship with the Central Server / Management Security Server environment.

The checked-in tasks include:

* retrieving a management request from the Central Server;
* approving the request;
* registering the management service provider;
* adding the management client to the Security Server;
* retrieving the Central Server management-service configuration;
* adding and configuring the management service on the Security Server;
* adding service rights for the `security-server-owners` group;
* enabling the management service.

These operations are driven by the endpoints and identifiers configured in the repository's group variables.

## 6. Configure timestamping

The role retrieves approved timestamping services and configures the Security Server with the selected TSA service where required by the current environment.

## 7. Add the member and configure DSS/subsystems

The configuration file defines the GovStack member and one or more DSS entries. The repository treats each DSS as a subsystem/client on the Security Server.

For each configured DSS/subsystem, the automation can:

* construct its hierarchical client identifier;
* create it as a Security Server client if it does not already exist;
* install a TLS certificate when one is configured;
* add OpenAPI 3 service descriptions;
* add WSDL service descriptions where configured;
* update backend service URLs;
* add service access rights;
* enable service descriptions.

The identifier format documented by the repository is:

* Member: `{instance}:{class}:{code}`
* DSS/subsystem: `{instance}:{class}:{code}:{DSS}`

## Configure services and access rights

The repository configuration guide models services beneath each DSS/subsystem.

A service can define values such as:

```yaml
services:
  - name: petstore
    openapi_url: http://petstore-api-service.petstore-ns.svc.cluster.local/openapi-spec.json
    service_url: http://petstore-api-service.petstore-ns.svc.cluster.local
    rights:
      - subject: "security-server-owners"
```

The key fields are:

* `name`: service identifier;
* `openapi_url`: location of the OpenAPI description;
* `service_url`: backend endpoint to which the Information Mediator routes requests;
* `rights`: clients/groups that are allowed to access the service.

The repository also supports WSDL service descriptions in the subsystem configuration tasks.

## Approval boundary

This phase prepares the Security Server and its service configuration, but the overall workflow still has an approval boundary.

{% hint style="warning" %}
The repository's quick-start documentation tells the user to send the deployment configuration to administrators and wait for the relevant Central Server administrators to approve the certificate before completing the final setup.

Do not treat the pre-approval playbook as the end of the setup process.
{% endhint %}

Once the required approval has happened, continue with:

```bash
ansible-playbook configure-step2.yml
```

## Source basis

This page is based on:

* `README.md`
* `GETTING_STARTED.md`
* `configure-step1.yml`
* `roles/configure_pre_approval/tasks/main.yml`
* `roles/configure_pre_approval/tasks/configure_subsystem.yml`
* `roles/configure_pre_approval/tasks/add_service_rights.yml`
* `roles/create_api_key/tasks/main.yml`
* `group_vars/CONFIG_DOCUMENTATION.md`


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation by asking a question.

Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:

```
GET https://experience-digital-transform.gitbook.io/experience-digital-transformation/information-mediator/configure-the-information-mediator-before-approval.md?ask=<question>&goal=<user_goal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.