PKI sign-on to CloudForms using RH SSO 7.2 – Part 2 of 2

In the previous post, we looked at configuring SSO 7.2 for mutual TLS, requesting a user certificate that is validated against a configured trust store.

In this post we’ll look at the second half of that task – configuring CloudForms for SAML authentication and enabling the X.509 Browser Flow in SSO.

Configuring CloudForms SAML authentication

This process is well documented, so please refer to that for the specifics.

Some things you need to watch out for when doing this, however:

  1. Make sure you have a user available in the same realm that CloudForms SAML is pointing to. In my example I have my users in a CloudForms realm, and they are synchronised from my personal IdM LDAP server. If you don’t have an equivalent, just manually create a user within SSO and set a password.
  2. You’ll be configuring the X.509 browser flow in the same realm that CloudForms SAML is pointing to.
  3. Ensure that you curl the https endpoint for the file idp-metadata.xml. The documentation has you curl a plain HTTP endpoint – this will result in the wrong configuration for SAML redirection from CloudForms.
curl -s -o idp-metadata.xml https://<redhatSSO-server>:8443/auth/realms/<miq-realm>/protocol/saml/descriptor
  1. Make sure you have groups configured in SSO that match the groups in CFME you want your user to have access to. In my example, I have created the group “EvmGroup-super_administrators” in SSO and assigned my SSO user to it. Otherwise you’ll end up with a login failed error at the CloudForms side, and an error message like this in evm.log:
[----] W, [2018-07-08T03:12:33.140829 #20394:b80448]  WARN -- : <AuditFailure> MIQ(Base.block in authorize) userid: [agoossen] - Authentication failed for userid agoossen, unable to match user's group membership to an EVM role
  1. When configuring your SAML assertion for groups, make sure you uncheck the box labelled Full group path.

If the SAML integration is successful, you should be able to login to SSO using the username and password you have configured for your testing user and successfully enter CloudForms.

The next step is removing the need to enter a username and password.

Configuring X.509 Browser Flow

Configuring the browser flow is also documented pretty thoroughly. Refer to that for specifics as well.

However, a couple of key points as part of this:

  1. This process relies on extracting some key value from part of the user’s presented certificate and matching that against an attribute in SSO’s user database. Choosing “Subject’s Common Name” will take the value of CN straight from the certificate – if that’s not what you want, choose one of the options that allows you to provide a regular expression:

  1. If you choose a mapping method of “Username or Email”, don’t set a user attribute. Let SSO manage it.
  2. If you want to have username/password as a fallback login option, make sure you leave the “Username Password Form” Auth Type as an ALTERNATIVE option. If you want to force X.509 authentication, use the X509/Validate Username execution and choose ‘REQUIRED’. If the user doesn’t provide a certificate they’ll get a fairly ugly JSON error message displayed. A better solution may be to set “verify-client=REQUIRED” in your SSO configuration, forcing the certificate to be provided when the TLS connection is established.
  3. By default, the Bypass identity confirmation option is off. This results in the user being prompted if they want to login with their certificate. If you want to skip this screen and transparently log the user in, set this to on.

The result, if everything is configured correctly, is that you can use your certificate to sign in to CloudForms directly, after a redirect via SAML and SSO:

Done!

Leave a Reply

Your email address will not be published. Required fields are marked *