Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
Bug 1519715 - Change of SAML2 key/certificate (OpenStack federated with RH SSH (keycloak)
Summary: Change of SAML2 key/certificate (OpenStack federated with RH SSH (keycloak)
Alias: None
Product: Red Hat OpenStack
Classification: Red Hat
Component: openstack-keystone
Version: 11.0 (Ocata)
Hardware: Unspecified
OS: Unspecified
Target Milestone: zstream
: 12.0 (Pike)
Assignee: John Dennis
QA Contact: nlevinki
Depends On:
TreeView+ depends on / blocked
Reported: 2017-12-01 09:40 UTC by Nikhil Shetty
Modified: 2019-03-29 06:33 UTC (History)
8 users (show)

Fixed In Version:
Doc Type: Release Note
Doc Text:
Clone Of:
Last Closed: 2018-12-13 16:40:25 UTC
Target Upstream Version:

Attachments (Terms of Use)

Description Nikhil Shetty 2017-12-01 09:40:46 UTC
Description of problem:

Cu. has successfully, Created stack using Federation with keystone using following official Documentation


They intend to change Certs keys inside RH SSO and need best practice or steps to replicate the same in openstack

Version-Release number of selected component (if applicable): OSP v11

How reproducible:

Steps to Reproduce:
1. Create Stack using following Doc.


2. Try to update Cert Keys inside RH SSO
3. Need steps to update the same in Openstack ocnfiguration.

Expected results: The key should get updated in side openstack controler nodes in file /etc/httpd/saml2/v3_keycloak_cscs_idp_metadata.xml

Comment 1 John Dennis 2017-12-04 15:57:56 UTC
The Realm Keys tab in RH-SSO to be best of my knowledge are not related to SAML, but this should really be confirmed with the RH-SSO team.

With SAML key data is exchanged via SAML metadata. There is metadata for the SP (e.g. Mellon) and there is separate metadata for the IdP (e.g. RH-SSO). The exchange of metadata is how each SAML party knows about the other party's configuration. If you change the keys on one side you need to generation the metadata from that provider and load it into the consuming provider. In other words if you change the IdP you need to get the IdP metadata and load it into the SP. On the other hand if you change the SP you need to get the metadata from the SP and load it into the IdP.

To get the IdP metadata from RH-SSO go to the Installation tab under the realm client and select IDPSSODescriptor.

This mellon doc discusses a variety of ways to get Mellon metadata and how to load IdP metadata:

You can also easily edit metadata and replace the <X509Certificate> element in the metadata with the contents of the PEM encoded cert (remove the PEM boundary markers first).

After changing metadata services need to be restarted.

But as I indicated above, I don't believe the Realm Keys are used for the IDPSSODescriptor, they do not look the same to me when I view them in my test installation, only the RH-SSO team can provider that information.

Comment 2 John Dennis 2017-12-04 18:13:50 UTC
Does this answer your question?

If you need further information with respect to RH-SSO you'll need to open a Jira as that product does not use bugzilla. The RH-SSO documentation on Realm Keys is here:

Unfortunately it does not discuss the relationship of these keys with the signing key used for the realm IdP. You may need to contact the RH-SSO and possibly open a documentation bug asking for this section to be expanded.

Comment 3 Nikhil Shetty 2017-12-18 12:24:11 UTC

It seems a work around to provide the new key via RH-SSO worked, but we should still be having a way to do so via Director so that it is not wiped out in Next update.

Would the Solution provided be the only way to do so? or would/ should we be running some additional Steps to do so via Director.

Comment 4 John Dennis 2017-12-18 15:37:07 UTC
Director currently does not support configuring federation, however in step 4.16 of the documentation cited in the first step a Swift artifact is created which uploads a tar archive containing the SAML configuration files to the overcloud nodes. You will want to update the tar archive with the new metadata so next time it's uploaded by Swift you preserve the changes. The tar archive is created in step 4.13

Therefore just edit the metadata in the fed_deployment directory and recreate the tar archive as shown in step 4.13.

Comment 5 John Dennis 2017-12-18 20:39:23 UTC
Changing this to a documentation bug.

Note You need to log in before you can comment on or make changes to this bug.