> 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/cloud.md).

# Cloud connector

The Cloud connector — a template-style connector that provisions users to a REST endpoint over HTTP(S).

The **Cloud connector** (`cloud-connector-rabbitmq`) is a lightweight, template-style connector that forwards provisioning operations to a REST endpoint over HTTP(S). Unlike vendor-specific connectors, it does not target a particular product: it POSTs the OpenIAM connector object as JSON to a cloud API that implements the expected endpoints.

| Operation                   | Supported       |
| --------------------------- | --------------- |
| Create / update user (Save) | ✅               |
| Delete user                 | ✅               |
| Suspend / resume user       | ✅               |
| Reset password              | ✅               |
| Search users                | ✅               |
| Test connection             | ✅               |
| **Group provisioning**      | ❌ Not supported |
| **Login (authentication)**  | ❌ Not supported |

## Use cases

* Integrating a **custom or in-house cloud application** that can expose a small REST API, without building a full connector.
* A starting point for development teams who want provisioning against a bespoke endpoint and are willing to implement the [REST contract](#the-rest-contract) on their side.
* **Not** a fit when you need group provisioning or a ready-made vendor integration — use a custom connector or the matching vendor connector instead.

## Versions and compatibility

There is no end-application version to match here. The Cloud connector does not target a product — it calls a REST service that **you** implement, so what has to stay compatible is the contract between the two, not a vendor's release.

<table><thead><tr><th width="187">Property</th><th>Value</th></tr></thead><tbody><tr><td><strong>End application</strong></td><td>Any service you expose that implements <a href="#the-rest-contract">the contract below</a></td></tr><tr><td><strong>Interface</strong></td><td>HTTP(S), with the OpenIAM connector object as a JSON body</td></tr><tr><td><strong>Base URLs</strong></td><td>Two constants compiled into the connector, <strong>not</strong> read from the managed system</td></tr><tr><td><strong>Authentication</strong></td><td>HTTP basic, from the connector's own properties</td></tr></tbody></table>

{% hint style="warning" %}
**The managed system's URL field is not used by this connector.** Every request is built from `https://customer.openiam.com/rest/api/cloud/users` or `.../cloud/passwords`, both declared as constants in the connector source. Setting a URL on the managed system changes nothing — pointing the connector at your own service means changing those constants and rebuilding it.
{% endhint %}

## The REST contract

Each operation is an HTTP call carrying the serialized OpenIAM **connector object** (user identity, attributes, and managed-system metadata) as the JSON body:

| Operation               | HTTP call                     |
| ----------------------- | ----------------------------- |
| Save (create or update) | `POST {base}/users/save`      |
| Delete                  | `DELETE {base}/users`         |
| Suspend                 | `POST {base}/users/suspend`   |
| Resume                  | `POST {base}/users/resume`    |
| Reset password          | `POST {base}/passwords/reset` |
| Search                  | `GET {base}/users`            |
| Test connection         | `GET {base}/users/test`       |

Your cloud API must implement these endpoints and return an HTTP success status; any REST error is reported back to OpenIAM as a failed operation with the error text.

{% hint style="warning" %}
**The base URL is a compile-time constant.** As shipped, the connector calls `https://customer.openiam.com/rest/api/cloud/…` — the endpoints are defined as constants in the connector source, not read from the managed-system configuration. To point the connector at **your** cloud API, change the URL constants and rebuild the connector (see Building a custom connector).
{% endhint %}

## Prerequisites

* A cloud API implementing the [REST contract](#the-rest-contract) below, reachable over HTTP(S) from the connector host.
* Credentials for the API (the connector sends HTTP Basic authentication).
* Because the endpoint base URL is a compile-time constant (see the warning above), a build environment for the connector if you need to repoint it.

## 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 cloud-connector-rabbitmq.jar > cloud.out &
```

{% endcode %}

Or, when managed by systemd, use the connector service unit (`openiam-connector@cloud-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="183">Deployment</th><th>Commands</th></tr></thead><tbody><tr><td>RPM (systemd)</td><td><code>systemctl start|stop|restart openiam-connector@cloud-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/cloud-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=CLOUD_Connector_1_Request -jar cloud-connector-rabbitmq.jar
```

{% endcode %}

| Property                                  | Default                      | Purpose                                                     |
| ----------------------------------------- | ---------------------------- | ----------------------------------------------------------- |
| `org.openiam.connector.queue`             | `CLOUD_Connector_1_Request`  | Request queue — must match the connector record in OpenIAM. |
| `org.openiam.connector.queueResponseName` | `CLOUD_Connector_1_Response` | Response queue.                                             |
| `org.openiam.connector.name` / `.type`    | `Cloud` / `Cloud Connector`  | Connector identity.                                         |
| `org.openiam.auth.basic.username`         | `openiam`                    | HTTP **Basic-auth** username sent to the target API.        |
| `org.openiam.auth.basic.password`         | `passwd!x123`                | HTTP **Basic-auth** password sent to the target API.        |

{% hint style="danger" %}
**Change the default credentials before deploying.** The connector ships with a default Basic-auth username and password (`openiam` / `passwd!x123`) in plain text in `application.properties`. These defaults are publicly known — override both properties with deployment-specific secrets (and protect the properties file), and require TLS on the target endpoint.
{% endhint %}

For this connector those properties are the whole configuration: the target URLs are compiled in and the managed system record supplies nothing. See [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 (this calls `GET {base}/users/test`).
{% endstep %}

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

{% step %}
Check the connector log (`cloud.out` or the container/service 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 `CLOUD_Connector_1_Request` exactly.        |
| Operations fail with a REST error | Target API unreachable, wrong credentials, or non-2xx response        | Verify the compiled-in endpoint URL, the Basic-auth properties, and the API's logs. |
| Group provisioning "does nothing" | Group operations are not supported by this connector                  | Expected — see the operations table above.                                          |
| `401` from the target API         | Default credentials still in place, or the API expects different auth | Override `org.openiam.auth.basic.*` and align with the API.                         |

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 a managed system — see [Registering the connector](/administration-guide/lifecycle/connectors-and-managed-systems.md). The **Connector Queue** on the connector record must match `org.openiam.connector.queue` exactly.

## Configuring the managed system

This connector takes nothing from the managed system record. The target URLs are compiled into the connector, and the credentials it presents come from its own properties — so the managed system's **URL**, **Login** and **Password** fields are not read.

Everything configurable lives under [Command-line parameters and properties](#command-line-parameters-and-properties).

## Attribute mapping and policy map

The connector sends the full connector object — the attributes produced by the managed system's policy map — as the JSON body. Map attributes in the [policy map](/administration-guide/lifecycle/policy-map.md) as usual; your cloud API decides which JSON fields it consumes.

## Reconciliation and synchronization

The `Search` operation (`GET {base}/users`) supplies records for synchronization. Configure a sync against the managed system as described in [Configuring synchronization](/administration-guide/lifecycle/synchronize-and-import-data.md); your API's search response provides the source records.


---

# 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/cloud.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.