ContentX scoping
Reviewers:
• Technical: Jeremy Agee
• Peer: Unknown
• QE: Jeremy Agee

Is this feature fully supported or technical preview?
• Full support: The feature should be fully supported upon release

Does the procedural content need to be tested by QE? Yes
Jeremy Agee will be the QE reviewer

Does the documentation epic need a release note in addition to the feature? No

Are there any existing upstream or internal resources that the writer can use for planning and drafting the content?
• Upstream: https://docs.openstack.org/keystone/latest/admin/federation/configure_federation.html#configuring-multiple-identity-providers
• Ansible playbook in development: https://github.com/openstack-k8s-operators/ci-framework/pull/3001/files
• Existing federation documentation for comparison: https://docs.redhat.com/en/documentation/red_hat_openstack_services_on_openshift/18.0/html/configuring_security_services/assembly_rhoso-federation

Does the content require input from multiple DFGs? No

Does the content need to be included in any of the following guides: Validated architecture, Planning, Deployment, Adoption?
No

The user journey for this feature targets adoption in greenfield deployments or expansions of existing ones.
• The primary focus discussed is documenting the implementation steps.

(Optional) Are there any additional content improvements you can also implement for the user when documenting this goal?
• It was agreed to document single and multiple IDP scenarios as separate procedures to improve user experience and reduce complexity.
• Further scoping will be done later for additional questions after more development is complete.

(Optional) Documentation outline
Based on the discussion, the documentation should cover the following key areas for configuring Keystone for multi-realm federation:

Prerequisites: Ensure RHOSO is installed and a RH-SSO federated solution is in the environment.

• Configuring Keystone as a Service Provider:
• Creating a new directory in the configuration area for Keystone to load federation-related files. Contents are mounted from a secret.
◦ Editing the OpenStackControlPlane manifest file (OpenStackControlPlane.yml) to add an extraMounts stanza under spec/keystone/template/extraMounts to define the secret mount.
◦ Creating a manifest file (e.g., keystone-httpd-override.yml) for a Secret that contains the Apache HTTPD configuration override for federation.
◦ Editing the secret manifest
◦ Defining endpoints in the Apache configuration using LocationMatch or Location directives
◦ Creating configuration files for each Identity Provider (e.g., client, comp, provider files) that reside within the mounted OIDCMetadataDir.
◦ Including the unique client ID and client secret for each IDP within their respective client configuration files in the metadata directory.
◦ Retrieving the entire JSON metadata from each IDP's well-known URL (e.g., https://

/realms/<realm>/.well-known/openid-configuration) and including it as the content for the 'provider' config file for that IDP
◦ Creating the secret (e.g., keystone-httpd-override) from the manifest file
◦ Applying changes to the OpenStackControlPlane manifest.
◦ Configuring the remote ID attribute in the Keystone template, setting remote_id_attribute to HTTP_OIDC_ISS under the [openid] section