> For the complete documentation index, see [llms.txt](https://docs.openiam.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.openiam.com/connector-configuration/thales-wsdl.md).

# Thales WSDL connector

Configure the Thales WSDL connector to provision users and groups to SafeNet Authentication Service via the BSIDCA SOAP web service.

The **Thales WSDL connector** (`thales-wsdl-connector-rabbitmq`) provisions users and groups to Thales **SafeNet Authentication Service** deployments through the **BSIDCA SOAP web service**. The connector loads the service from the WSDL URL you configure and signs in with the configured operator credentials (`connect` on the BSIDCA port).

| Operation                           | Supported                                  |
| ----------------------------------- | ------------------------------------------ |
| Create / update user (Save)         | ✅                                          |
| Delete user                         | ✅                                          |
| Suspend / resume user               | ✅                                          |
| Reset password                      | ✅                                          |
| Search users                        | ✅                                          |
| Group create/update, delete, search | ✅                                          |
| Test connection                     | ✅                                          |
| Login                               | ❌ Not implemented in the current connector |

This is the most complete of the two Thales connectors — including full **group provisioning**, which the [REST connector](/connector-configuration/thales.md) lacks.

{% hint style="info" %}
This is the SOAP alternative to the REST-based [Thales connector](/connector-configuration/thales.md). Choose based on which API your Thales environment exposes — BSIDCA (SOAP/WSDL) is typical for SafeNet Authentication Service (on-prem/managed) deployments.
{% endhint %}

## Use cases

* Full **user and group lifecycle provisioning** to SafeNet Authentication Service deployments exposing the BSIDCA web service.
* **Importing SAS users and groups** into OpenIAM via synchronization.
* The right choice when you need **group provisioning** to Thales — the REST connector does not implement it.

## Versions and compatibility

The end application is the **Thales (CRYPTOCard) BlackShield** service, reached over SOAP rather than REST. The connector calls the BSIDCA web service, and the endpoint comes from the managed system.

<table><thead><tr><th width="197">Property</th><th>Value</th></tr></thead><tbody><tr><td><strong>Platform</strong></td><td>Thales / CRYPTOCard BlackShield</td></tr><tr><td><strong>Interface</strong></td><td>SOAP, the BSIDCA web service</td></tr><tr><td><strong>Host</strong></td><td>The managed system's URL, for example <code>https://&#x3C;host>/bsidca/BSIDCA.asmx</code></td></tr></tbody></table>

{% hint style="info" %}
For Thales **SafeNet Trusted Access**, which speaks REST, use the [Thales connector](/connector-configuration/thales.md) instead. The two are different products and are not interchangeable.
{% endhint %}

## Prerequisites

* A BSIDCA **operator account** with permission to manage users and groups.
* The **BSIDCA WSDL URL** of your SafeNet Authentication Service instance.
* Network access from the connector host to the BSIDCA endpoint (HTTPS).

## Installing the connector

### Kubernetes

In Kubernetes deployments, the connector is deployed as part of OpenIAM — enable it in your deployment configuration; no separate installation is required.

### RPM

Run the connector JAR directly:

{% code overflow="wrap" %}

```bash
java -Dlogging.level.root=INFO -Dconfpath=/data/openiam/ -jar thales-wsdl-connector-rabbitmq.jar > thales-wsdl.out &
```

{% endcode %}

Or, when managed by systemd, use the connector service unit (`openiam-connector@thales-wsdl-connector-rabbitmq`). To deploy on a separate host, see [Connectors via RPM](/installation/rpm/rpm-single-node/add-a-connector.md).

## Starting, stopping, and restarting

<table><thead><tr><th width="157">Deployment</th><th>Commands</th></tr></thead><tbody><tr><td>RPM (systemd)</td><td><code>systemctl start|stop|restart openiam-connector@thales-wsdl-connector-rabbitmq</code></td></tr><tr><td>RPM (manual)</td><td>Start with the <code>java -jar</code> command above; stop by killing the process.</td></tr><tr><td>Kubernetes</td><td><code>kubectl rollout restart</code> the connector deployment.</td></tr></tbody></table>

## Command-line parameters and properties

The connector is a Spring Boot application. Its defaults ship inside the jar, and you override them in either of two places:

* **An external property file**, read at `${confpath}/conf/properties/oracle-workday-connector-rabbitmq.properties`. The file is optional, and `confpath` is itself a system property, set with `-Dconfpath=/data/openiam/`.
* **Directly on the command line**, as `-D` arguments, which win over the file.

{% code overflow="wrap" %}

```bash
java -Dconfpath=/data/openiam/ -Dlogging.level.root=INFO -Dorg.openiam.connector.queue=THALES_WSDL_Connector_1_Request -jar thales-wsdl-connector-rabbitmq.jar
```

{% endcode %}

| Property                                  | Default                                 |
| ----------------------------------------- | --------------------------------------- |
| `org.openiam.connector.queue`             | `THALES_WSDL_Connector_1_Request`       |
| `org.openiam.connector.queueResponseName` | `THALES_WSDL_Connector_1_Response`      |
| `org.openiam.connector.name` / `.type`    | `Thales WSDL` / `Thales WSDL Connector` |

{% hint style="danger" %}
**The external property file this connector reads is named after a different connector.** It reads `oracle-workday-connector-rabbitmq.properties` — the Workday connector's file — not a file of its own. Two consequences: overrides written to `thales-wsdl-connector-rabbitmq.properties` are ignored, because nothing reads that path; and an override written for Workday is applied here as well, including the queue name. Until this is corrected in the product, set overrides for this connector on the command line as `-D` arguments, where they are unambiguous.
{% endhint %}

The connection details themselves are **not** set here — they are managed system parameters, covered under [Configuring the managed system](#configuring-the-managed-system).

## Verifying the connector is running

{% stepper %}
{% step %}
In the Webconsole, open the managed system — the **Running connector status** indicator must be green.
{% endstep %}

{% step %}
Click **Test Connection** — it must return success.
{% endstep %}

{% step %}
In the RabbitMQ management console, confirm the `THALES_WSDL_Connector_1_Request` queue exists and has a consumer.
{% endstep %}

{% step %}
Check the connector log for startup errors.
{% endstep %}
{% endstepper %}

## Troubleshooting

| Symptom                           | Likely cause                                                           | Resolution                                                                         |
| --------------------------------- | ---------------------------------------------------------------------- | ---------------------------------------------------------------------------------- |
| Connector never receives messages | Queue-name mismatch                                                    | The connector record's queue must equal `THALES_WSDL_Connector_1_Request` exactly. |
| Connector cannot load the service | The WSDL URL is wrong or unreachable from the connector host           | Verify the URL opens from the connector host and returns the WSDL document.        |
| Operations fail after connecting  | The operator account lacks permissions, or the BSIDCA `connect` failed | Verify Login/Password and the operator's rights in SAS.                            |
| Login operation does nothing      | Login is not implemented in this connector                             | Expected — see the operations table above.                                         |

See also: [general connector troubleshooting](/connector-configuration/4-troubleshootingconnector.md) and the [connector error-code reference](/connector-configuration/4-troubleshootingconnector.md#connector-error-codes).

## Registering the connector in OpenIAM

Register the connector under **Provisioning → Connectors** and attach it to the managed system — see [Registering the connector](/administration-guide/lifecycle/connectors-and-managed-systems.md).

## Configuring the managed system

<table><thead><tr><th width="189">Managed-system field</th><th>Value</th></tr></thead><tbody><tr><td><strong>URL</strong></td><td>The <strong>BSIDCA WSDL URL</strong> of your SafeNet Authentication Service instance (the connector reads the service definition from this URL).</td></tr><tr><td><strong>Login</strong> / <strong>Password</strong></td><td>The BSIDCA operator account credentials used to connect.</td></tr></tbody></table>

The connector caches the SOAP port per WSDL URL and reconnects as needed.

## Attribute mapping and policy map

Map OpenIAM user attributes to the SAS user fields in the managed system's [policy map](/administration-guide/lifecycle/policy-map.md). Group assignments provision SAS group memberships.

## Reconciliation and synchronization

The user and group searches supply SAS records as source data. Configure a sync against the managed system as described in [Configuring synchronization](/administration-guide/lifecycle/synchronize-and-import-data.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://docs.openiam.com/connector-configuration/thales-wsdl.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.