Skip to content

Fortified IDDocs

Test a federated RP with OpenID Foundation

Prepare a separate Access RP configuration for OpenID Foundation federation conformance testing.

The OpenID Foundation conformance suite can exercise Access as a deployed federation entity and as an RP joined to a federation run by the test suite. Use this page with the Management Center setup guide and the Foundation's current federation testing instructions. The suite labels these federation plans as early tests; a passing plan is test evidence, not by itself a certification claim.

Create a second Federation Entity and OIDC RP authenticator for the Foundation tests. Give the test entity its own public HTTPS Entity ID and Entity Configuration path, and select it only in the test RP. Leave any Sweden Connect Entity, Trust Anchor, OP selection and login flow in place. Each test RP can be connected to a separate Access login flow or test application, so both integrations remain available at the same time.

Reserve a distinct public HTTPS Entity ID and trusted TLS route before opening a test plan. The plan supplies the test Trust Anchor and OP identifiers needed to finish the configuration. After linking the test RP and deploying, use the Entity Configuration viewer to check iss, sub, signing key and openid_relying_party metadata. An external fetch of <entity_id>/.well-known/openid-federation must return the signed JWT.

Sign in at the OpenID Foundation conformance suite, create a new test plan in the OpenID Federation family and enable Show early version tests. Select Entity joined to test federation RP test, discovery for Entity Configuration location and automatic for client registration. Enter a unique alias and Access's public test entity_identifier. The plan displays the test Trust Anchor Entity ID. The suite acts as both Trust Anchor and OP for this plan. See its RP test setup for the current form fields.

In the plan, generate or provide the suite's op_ec_jwks, op_server_jwks and trust_anchor_jwks as instructed there. Keep private test keys on the suite side. In Access, pin only the public Trust Anchor federation JWKS and use the plan's Trust Anchor Entity ID. Add that ID to the test Federation Entity's Authority hints. The suite's OP is an immediate subordinate of its Trust Anchor; configure One-hop trust chain with the Trust Anchor's advertised Fetch Endpoint if that is the endpoint exposed by the plan. Verify the endpoint in the suite's current Trust Anchor metadata rather than guessing its URL.

Set the test OIDC RP's Provider discovery to OpenID Federation, link it to the test Federation Entity and set its OP Entity ID to the one shown by the test plan. Select Automatic client registration and Private key JWT. Save, deploy and confirm that the test Entity Configuration contains this RP's public keys and redirect URI. Run the plan's individual tests through Run Test and follow the suite's browser instructions for login steps.

The separate Deployed federation entity test checks published entity metadata and federation endpoint responses. Select discovery, enter the deployed test entity_identifier, the Trust Anchor for the federation in which that entity is joined, and its public trust_anchor_jwks when needed. At present the Foundation's plan instructions describe automatic registration as the supported selection. A deployed entity must actually be joined to the indicated federation for chain-based checks; publishing an Entity Configuration alone does not create a Subordinate Statement.

For failed tests, retain the test name, plan alias, Access logs and the relevant Entity Configuration and resolved metadata. Do not change trust or token validation merely to turn a result green. Compare the failure with the Foundation's test instructions and investigate whether it comes from Access configuration, Access behavior or the suite. The Foundation directs test questions to its conformance-suite project or [email protected].