RCS configuration migration FAQ
What has changed?
Ping Identity has introduced the ability to configure access rules for the openicf WebSocket
endpoint used by Advanced Identity Cloud connector servers.
Why do I need to add this feature to my configuration?
The feature lets you lock down Advanced Identity Cloud connector servers so that each connector server can be accessed only by an RCS connector using that connector server’s designated OAuth 2.0 client. This prevents an RCS connector associated with a particular connector server from gaining unauthorized access to the resources of other connector servers.
As each Advanced Identity Cloud customer has a different arrangement of connector servers, Ping Identity can’t configure this feature automatically. You must update the configuration in each of your tenant environments to suit your own connector server arrangement.
Is the feature enabled by default for existing tenants?
No, the feature isn’t enabled by default for existing tenant environments. To enable it, you must add access and authentication configuration for each of your existing connector servers. This process is explained in How can I upgrade my tenants?
| In each tenant environment, the feature is enabled as soon as you configure an access rule for any connector server. You must configure all existing connector servers at the same time per environment to prevent access issues. |
Is the feature enabled by default for new tenants?
Yes, the feature is enabled by default for new tenant environments. However, it’s only configured
for connector servers created using the default RCSClient OAuth 2.0 client. If you create a
connector server using a specific OAuth 2.0 client, you must add access and authentication
configuration. This process is explained in step 2 in How can I upgrade my tenants?
How can I upgrade my tenants?
This depends on whether the connector servers in your existing tenants are configured to use the
default RCSClient OAuth 2.0 client, specific OAuth 2.0 clients, or a combination of both.
| The process of setting up an OAuth 2.0 client with a connector server is explained in Register a remote server. |
Connector servers using the default RCSClient OAuth 2.0 client
If any of your existing connector servers use the default RCSClient OAuth 2.0 client, you need to check or modify the configuration as follows.
| To ensure that only trusted connectors access a connector server, Ping Identity recommends that you migrate each of these connector servers to use specific OAuth 2.0 clients. |
Authentication configuration
For these connector servers, there’s no need to update the authentication configuration, as Advanced Identity Cloud already has the following internal configuration:
{
"_id": "authentication",
"rsFilter": {
...
"staticUserMapping": [
{
"subject" : "RCSClient",
"roles" : [
"rcsclient-authorized"
],
}
...
],
...
}
}Access configuration
-
If your tenant was created before June 10, 2025, you’ll need to add the following access configuration. Use the instructions in Change the access configuration over REST to make the update.
Access configuration (endpoint/openidm/config/access){ "_id": "access", "configs": [ ... { "methods": "read", "pattern": "*", "roles": "~rcsclient-authorized", "servlet": "openicf" }, ... ] } -
If your tenant was created on or after June 10, 2025, you don’t need to update the access configuration. The configuration in the previous bullet point is already present.
Connector servers using specific OAuth 2.0 clients
If any of your existing connector servers use a specific OAuth 2.0 client, you need to check or modify the configuration as follows.
Authentication configuration
For each of these connector servers, add authentication configuration based on the following example. Use the instructions in Change the authentication configuration over REST to make the update.
/openidm/config/authentication){
"_id": "authentication",
"rsFilter": {
...
"staticUserMapping": [
{
"subject": "<oauth-client-id>", (1)
"roles": [
"<role-name>" (2)
]
}
...
],
...
}
}| 1 | Replace <oauth-client-id> with the OAuth 2.0 client ID for the connector server.
For example, myrcs1-client.
This value is set in connectorserver.clientId in your RCS connector configuration. |
| 2 | Replace <role-name> with the name of a custom role.
For example, myrcs1-client-authorized.
Ping Identity recommends that you create a separate role for each connector server. |
Access configuration
For each of these connector servers, add an access rule based on the following example. Use the instructions in Change the access configuration over REST to make the update.
+
.Access configuration (endpoint /openidm/config/access)
{
"_id": "access",
"configs": [
...
{
"servlet": "openicf",
"pattern": "<connector-server-name>", (1)
"roles": "<role-name>", (2)
"methods": "read"
},
...
]
}| 1 | Replace <connector-server-name> with the name of the connector server.
For example, myrcs1.
This value is set in connectorserver.connectorServerName in your RCS connector configuration. |
| 2 | Replace <role-name> with the name of the custom role specified in the corresponding staticUserMapping authentication configuration.
For example, myrcs1-client-authorized. |
Verify the configuration
Restart all your RCS connectors:
-
Connectors that have correctly configured connector servers show the following message:
RCS 1.5.20.29 started. Press q to shutdown. -
Connectors that have incorrectly configured connector servers show the following message and require troubleshooting:
RCS 1.5.20.29 started. Press q to shutdown. Jun 19, 2025 12:33:36 pm INFO o.f.o.f.client.ConnectionManager: [myrcs1] Connector Server: Access Forbidden - closing connection Jun 19, 2025 12:33:36 pm INFO o.f.o.f.c.ClientRemoteConnectorInfoManager: [myrcs1] Connection to server failed: 403 - Access Forbidden Jun 19, 2025 12:33:36 pm WARN o.f.o.f.c.ClientRemoteConnectorInfoManager: [myrcs1] StaggeredConnectionCreator: Exception while connecting WebSocket: java.util.concurrent.ExecutionException: org.identityconnectors.framework.common.exceptions.InvalidCredentialException: 403 - Access Forbidden