# Set up a federated RP in Management Center

Documentation owner: product `access`; documentation version: `next`.
Source: `content/products/access/next/authenticators/protocol-managers/oidc/openid-federation-management-center.md` at commit `eaf7a020437971baeee95e87eaf963636040ac71`.

Use this guide to connect an Access OIDC RP authenticator to an external OpenID Provider (OP) through OpenID Federation. You configure a Federation Entity for Access's public identity and trust, then create an OIDC RP authenticator for the login flow. For the concepts behind these resources, see the [OpenID Federation overview](/products/access/next/authenticators/protocol-managers/oidc/openid-federation-overview/).

:::note
The **OIDC > Add Relying Party** action creates a client of Access's own OP. For this guide, add an **OIDC RP** under **Authenticators** instead. That authenticator connects Access to an external OP.
:::

## Before you start

Get these values from your deployment and federation operator:

| Value | What it is used for |
| --- | --- |
| Access Entity ID | The public HTTPS URL identifying this RP in the federation. The federation must be able to reach its Entity Configuration at `<entity_id>/.well-known/openid-federation`. |
| OP Entity ID | The exact public Entity ID of the external OP you want to use. |
| Trust Anchor Entity ID and public JWKS | The root of trust and its federation signing keys. Obtain the JWKS through a trusted channel. |
| Federation endpoint | The Trust Anchor's Fetch Endpoint or Resolve Endpoint, depending on the selected trust-chain method. |
| Authority hints | Entity IDs of Access's Immediate Superiors, if the federation places the RP under an intermediate. |
| RP redirect URI | The HTTPS callback URI at which this Access OIDC RP receives the authorization response. It must be allowed by the OP's registration policy. |

Also prepare a public HTTPS route and trusted TLS certificate for the Entity Configuration endpoint, a configured **HTTP listener**, and an **Outbound HTTP client** that can reach the federation and OP. The names of these resources vary by installation; do not assume a resource named `default` exists. Ask the federation operator whether the RP must be added as a subordinate before the first test and which client-registration method the OP supports. This membership step is separate from client registration.

## Configure the Federation Entity

### Create the entity

In **Configuration > OIDC**, choose **Add Federation Entity**. Enter a display name and the public **Entity ID**; Management Center generates the internal resource ID. Create the entity to open its tabs. Access also creates a dedicated local federation signing key. The Entity ID must be the URL from which the published Entity Configuration will be served, including its path if it has one.

### Configure federation trust

Open **Federation trust** and select the **Trust chain resolution method** required by your federation:

* **One-hop trust chain** when the OP is an immediate subordinate of the configured Trust Anchor.
* **Bottom-up trust chain resolution** when Access must follow `authority_hints` and build the chain locally.
* **Single point of trust resolution** when Access should use the Trust Anchor's Resolve Endpoint.

Enter the Trust Anchor's exact **Entity ID** and public **JWKS**. For the first two methods, enter its **Fetch Endpoint**; for the third, enter its **Resolve Endpoint**. Add **Authority hints** for this RP's Immediate Superiors when the federation assigns them. Add **Required trust marks** only if your federation requires the OP to present them; supply the mark type and trusted issuer details it specifies.

### Review the other entity tabs

In **Relying party**, select the **RP metadata profile** required by the federation. Use **generic** unless a specific profile applies. Leave **OIDCRP authenticator** empty until the authenticator exists; linking from the authenticator later fills it in.

In **Signing**, confirm the generated **Federation signing keys** entry. **Entity Configuration lifetime** defaults to 3600 seconds and controls the expiration of newly issued Entity Configuration JWTs. The federation key belongs to this Access deployment; the external OP does not provide it.

In **Advanced**, choose the configured **HTTP listener** that serves Entity Configuration and an **Outbound HTTP client** for federation requests. The **Registration store** matters when the linked RP uses explicit registration: the default file store is for one Access node, while a clustered deployment needs a shared JDBC store. Save the changes.

## Create and link the OIDC RP authenticator

### Add the authenticator

Under **Configuration > Authenticators**, choose **Add authenticator** and then **OIDC RP**. An outbound HTTP client must already be configured for this action to be available. Open the new authenticator's **Overview** tab and set **Provider discovery** to **OpenID Federation**.

### Select the federation and registration method

In **Provider & registration**, select the Federation Entity you just created. Enter the external OP's exact **OP Entity ID** and choose the **Client registration** method supported by that OP:

* **Automatic** uses this RP's Entity ID as its client ID and requires `private_key_jwt`. This is a useful first configuration when the OP supports it.
* **Explicit** obtains client credentials from the OP's federation registration endpoint and stores them. See [Explicit registration and clustering](/products/access/next/authenticators/protocol-managers/oidc/openid-federation-explicit-registration/) before using it in a multi-node deployment.
* **Pre-registered** uses a client ID and credentials that the OP has already assigned to this RP.

Saving the RP links it back to the selected Federation Entity. Check the entity's **Relying party** tab afterward: **OIDCRP authenticator** should show this authenticator.

### Set the OIDC request values

In **Request & authentication**, set the **Redirect URI** agreed with the OP. Keep **Scopes** at `openid` unless the integration needs more scopes, and keep **Use PKCE** enabled unless the OP's documented behavior requires otherwise. For **Automatic** registration, select **Private key JWT** for token endpoint authentication. Management Center creates a dedicated RP signing key when you save; its public key is included in the Federation Entity's `openid_relying_party` metadata. This RP key and the Federation Entity signing key have different roles.

For **Pre-registered**, enter the OP-issued **Client ID** and the authentication credentials it requires. The **Claims & tokens**, **Error handling**, and **Advanced** tabs let you adjust claims, failure handling, outbound HTTP and other integration-specific settings. Review the **Outbound HTTP client** in **Advanced** before testing. Save the authenticator.

### Connect it to a login flow

Add the OIDC RP authenticator to the Access authentication flow that should send users to the external OP. Your local test application or Access OP needs to invoke that flow; merely creating the authenticator does not start a browser login. If you are using Access as an OP for the test application, its local OIDC provider and client registration are separate from the external federated RP configured above.

## Deploy and verify

Save any remaining configuration changes and choose **Deploy** in Management Center. Confirm that Access starts without configuration errors. Open the Federation Entity's **Overview** tab and click **Entity Configuration**. The viewer shows the signed JWT's **Payload**, **Header**, and **Raw JWT**. Confirm that the issuer and subject are the Access Entity ID, that `openid_relying_party` contains the expected redirect URI and public RP key, and that the signing key in the JWT header matches a public key in the entity's top-level `jwks`.

Fetch `<entity_id>/.well-known/openid-federation` from outside Access over HTTPS as a second check. This endpoint returns a signed JWT, so a browser may download it instead of rendering a page. Finally, run a login through the flow containing the OIDC RP and confirm that Access resolves the intended OP, redirects the browser to it, and completes the authorization response. A visible Entity Configuration alone does not prove that trust resolution or the login flow works.

If the OP cannot resolve this RP, first verify the public URL, TLS chain, Entity ID, authority hints and federation operator registration. If Access cannot resolve the OP, check the Trust Anchor keys, the selected Fetch or Resolve Endpoint, the OP Entity ID and outbound HTTP connectivity. See the [configuration reference](/products/access/next/authenticators/protocol-managers/oidc/openid-federation-configuration/) for individual fields or [manual configuration](/products/access/next/authenticators/protocol-managers/oidc/openid-federation-rp/) for the equivalent Access JSON resources.