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.

Read more “PKI sign-on to CloudForms using RH SSO 7.2 – Part 2 of 2”

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

(Part 2 is available here!)

With the advent of Public Key Infrastructure across organisations, it became possible to authenticate a user based on the certificate they provide. Red Hat Single Sign On 7.2 is able to authenticate users based on a provided certificate, matching some value from the certificate (e.g. CN, email) against RH SSO’s internal database of users.

When combined with the Security Assertion Markup Language (SAML) authentication out-of-the-box in CloudForms, we can achieve passwordless, certificate-based sign on to CloudForms.

There are three main areas to this configuration::

  1. Configuring RH SSO 7.2 for mutual TLS, requesting a client certificate.
  2. Configuring CloudForms for SAML against RH SSO 7.2.
  3. Enable the X.509 browser authentication flow in RH SSO 7.2.

Step 1 is the focus of this blog post. Steps 2 and 3 will follow in the next post.

Read more “PKI sign-on to CloudForms using RH SSO 7.2 – Part 1 of 2”

NEED_KEY_GEN_PERMS error when using ipa-getcert

If you run into this error, it’s telling you that certmonger doesn’t have the necessary permissions to write the key and certificate to the filesystem. That leaves one of two things:

  1. A filesystem permission issue, although given certmonger runs as root this seems unlikely (are you trying to write the key to an NFS share that doesn’t have no_root_squash set?).
  2. An SELinux denial.

If it’s number 2, you’ll see something like this out of audit2why -a:

[root@sso72 rh-sso-7.2]# audit2why -a
type=AVC msg=audit(1530787070.795:1633): avc:  denied  { create } for  pid=24058 comm="certmonger" name="sso.key" scontext=system_u:system_r:certmonger_t:s0 tcontext=system_u:object_r:admin_home_t:s0 tclass=file
        Was caused by:
                Missing type enforcement (TE) allow rule.

                You can use audit2allow to generate a loadable module to allow this access.

type=AVC msg=audit(1530787272.111:1634): avc:  denied  { write } for  pid=24019 comm="certmonger" name="configuration" dev="vda1" ino=12588752 scontext=system_u:system_r:certmonger_t:s0 tcontext=system_u:object_r:usr_t:s0 tclass=dir
        Was caused by:
                Missing type enforcement (TE) allow rule.

                You can use audit2allow to generate a loadable module to allow this access.

certmonger has policy to allow it to write to cert_t, which is everything under /etc/pki.

Change your ipa-getcert request to store the generated cert and key under /etc/pki/ and you should be good!