Documentation for Federated (OIDC) Keystone adoption#1062
Documentation for Federated (OIDC) Keystone adoption#1062xek wants to merge 2 commits intoopenstack-k8s-operators:mainfrom
Conversation
|
Skipping CI for Draft Pull Request. |
|
[APPROVALNOTIFIER] This PR is NOT APPROVED This pull-request has been approved by: The full list of commands accepted by this bot can be found here. DetailsNeeds approval from an approver in each of these files:Approvers can indicate their approval by writing |
|
This PR is stale because it has been for over 15 days with no activity. |
xek
force-pushed
the
federation_adoption_docs
branch
from
a9ee74c to
47064a9
Compare
|
Looks good, also adding @klgill |
| @@ -0,0 +1,117 @@ | |||
| _mod-docs-content-type: PROCEDURE | |||
| [id='configuring-federation-for-keystone_{context}'] | |||
There was a problem hiding this comment.
| [id='configuring-federation-for-keystone_{context}'] | |
| [id="configuring-federation-for-keystone_{context}"] |
| @@ -0,0 +1,117 @@ | |||
| _mod-docs-content-type: PROCEDURE | |||
There was a problem hiding this comment.
| _mod-docs-content-type: PROCEDURE | |
| :_mod-docs-content-type: PROCEDURE |
|
|
||
| = Configuring OIDC federation for the Identity service | ||
|
|
||
| To let {identity_service_first_ref} trust an external OpenID Connect (OIDC) identity provider, apply the federation configuration and verify that federated users can authenticate. |
There was a problem hiding this comment.
| To let {identity_service_first_ref} trust an external OpenID Connect (OIDC) identity provider, apply the federation configuration and verify that federated users can authenticate. | |
| To allow the {identity_service_first_ref} to trust an external OpenID Connect (OIDC) identity provider, apply the federation configuration and verify that federated users can authenticate. |
"Allow" seems like a stronger verb than "let."
| + | ||
| ---- | ||
| $ oc create secret generic keycloakca \ | ||
| --from-file=KeyCloakCA=keycloak-ca.crt -n openstack |
There was a problem hiding this comment.
| --from-file=KeyCloakCA=keycloak-ca.crt -n openstack | |
| --from-file=KeyCloakCA=<keycloak-ca.crt> -n openstack |
| --from-file=KeyCloakCA=keycloak-ca.crt -n openstack | ||
| ---- | ||
| + | ||
| * Replace `keycloak-ca.crt` with the path to the CA file you want to use. |
There was a problem hiding this comment.
| * Replace `keycloak-ca.crt` with the path to the CA file you want to use. | |
| where: | |
| `<keycloak-ca.crt>`:: Replace with the path to the CA file you want to use. |
| customConfigSecret: keystone-httpd-override | ||
| ---- | ||
| + | ||
| * Ensure you merge the patch with any existing custom configuration for the {identity_service}. |
There was a problem hiding this comment.
Are you saying that customers should update this example with their own existing custom configuration for the {identity_service}?
| $ openstack token issue | ||
| ---- | ||
| + | ||
| This command should return an access token issued for the federated user. |
There was a problem hiding this comment.
| This command should return an access token issued for the federated user. | |
| This command should return an access token that is issued for the federated user. |
| OS_ACCESS_TOKEN=$(openstack token issue -f value -c id) \ | ||
| openstack project show <project id> | ||
| ---- | ||
| + |
There was a problem hiding this comment.
| + | |
| + | |
| where: | |
| `<project_id>`:: Replace with the ID of your OpenStack project. |
@xek Is the description of this value accurate?
| OS_AUTH_URL=https://keystone-public-openstack.apps-crc.testing/v3 \ | ||
| OS_AUTH_TYPE=v3oidcaccesstoken \ | ||
| OS_ACCESS_TOKEN=$(openstack token issue -f value -c id) \ | ||
| openstack project show <project id> |
There was a problem hiding this comment.
| openstack project show <project id> | |
| openstack project show <project_id> |
| openstack project show <project id> | ||
| ---- | ||
| + | ||
| A successful response confirms that the federated OIDC configuration is active on the podified Keystone deployment. |
There was a problem hiding this comment.
@xek Can you provide an example of a successful response?
Also, what should customers do if the response fails?
- Fix _mod-docs-content-type attribute syntax (add colon prefix) - Use double quotes for id attribute - Change "To let" to "To allow" for stronger verb - Use angle brackets for placeholder values in commands - Replace bullet-point replacements with "where:" definition lists - Change "required for" to "that are required for" - Add detailed descriptions for client_secret, crypto_passphrase placeholders - Fix "access token issued" to "access token that is issued" - Fix "<project id>" to "<project_id>" with where clause
|
This PR is stale because it has been for over 15 days with no activity. |
3 participants
Jira: https://issues.redhat.com/browse/OSPRH-19963
Jira: https://issues.redhat.com/browse/OSPRH-19960