Related: EPTS-4294

Problem:

Opti ID is currently only available for environments hosted within DXP. Many DXP customers run one or more additional environments outside DXP, in our case a self-hosted Test environment in our own Azure subscription, used for QA before code reaches the DXP Integration environment.

Because Opti ID cannot be enabled there, we cannot authenticate CMS editors and administrators in that environment using the same mechanism we use everywhere else. This creates a permanent configuration divergence between our QA environment and every environment downstream of it.

Why this matters:

Authentication and authorization are exactly the kind of thing QA exists to catch. With Opti ID unavailable in our Test environment, we would have to:

maintain a second, parallel authentication configuration purely for QA;
test Opti ID-dependent behaviour (role mapping, access rights, session handling, product switching) for the first time in a DXP environment rather than before it; and accept that any Opti ID-related defect surfaces later in the pipeline, where it is more expensive to fix.

For CMS 13 this becomes sharper, since Opti ID gates Opal, the Embedded DAM, and Optimizely Connect Platform. Any feature depending on those cannot be meaningfully QA'd outside DXP at all.

Requested capability:

The ability for a DXP customer to register one or more additional, customer-controlled hostnames and redirect URIs against their existing Opti ID configuration, for example, permitting a nominated non-production hostname to authenticate against the Integration environment's Opti ID instance.

This is conceptually the same allowance already made for local development, where a non-DXP host (localhost on specified ports) is permitted to use the Integration environment's Opti ID credentials. We are asking for that same principle to extend to a customer-managed non-production environment with a stable hostname, which is arguably a lower-risk case than localhost, since the host is fixed, TLS-terminated, and under our control.

Suggested constraints:

Restricted to non-production environments only
Limited to a small number of additional hostnames per customer
Requires HTTPS and a verified domain
Provisioned by Optimizely on request rather than fully self-service
Tied to the Integration environment's credentials rather than issuing a new Opti ID instance

Relationship to the planned self-service redirect URI portal

The CMS 13 FAQ notes that a self-service portal for managing redirect URIs is planned. We would ask that its scope explicitly include hostnames outside DXP, not only DXP-hosted environments and localhost. If that portal covers this case, it resolves our request entirely.

Current workaround and its cost:

Our only current option is to run our Test environment on a different authentication scheme from all other environments, which means the authentication path is untested until it reaches DXP. If that is unworkable for us, the alternative is deferring Opti ID adoption entirely, which in CMS 13 also defers Opal, DAM and OCP.