Skip to content

Instantly share code, notes, and snippets.

@frasertweedale

frasertweedale/caacl-future.rst

Created October 24, 2016 23:34
Show Gist options
  • Save frasertweedale/6093f2312d16b3958374cc15b55b4d63 to your computer and use it in GitHub Desktop.
Save frasertweedale/6093f2312d16b3958374cc15b55b4d63 to your computer and use it in GitHub Desktop.
Download ZIP
Discussion: CA ACL enhancements
Raw
caacl-future.rst

Future of CA ACLs and cert-request validation

This document details some limitations in the current CA ACL and certificate request features and proposes (at a very high-level) a way forward for FreeIPA to support more use cases and give administrators more fine-grained control of certificate issuance authorisation. Feedback and additional use cases are sought.

The current controls governing certificate issuance authorisation are limited, falling short for a number of important use cases:

1. Limited operator authorisation

  • Currently a single permission, request certificate, controls whether an operator can issue a certificate, along with the ability to write the subject entity's userCertificate attribute. This check is waived for "self-service" requests and for host principal operators. (The request is still subject to CA ACLs, unless the operator has the request certificate ignoring caacl permission, and userCertificate attribute write access checks).
  • A use case where current implementation falls short: only vpnadmins user group should be able to issue certs for hosts in vpnservers hostgroup (using VPN profile and CA), and only webadmins user group should be able to issue certs for hosts in webservers hostgroup (using HTTPS profile and CA). Currently, request certificate permission is required to request the cert, but having that permission means that the operator could request VPN or HTTPS certs regardless of group membership.

2. Lack of ability to enable/disable self-service

  • For self-service requests (operator is subject), the request certificate permission is not checked. If a CA ACL allows a particular CA+profile to issue a cert to the subject, then self-service is unconditionally allowed. This is not good enough, e.g. if some kind of certificate, though appropriate for the subject, should only be issued by an admin.
  • Proper operator authorisation (use case (1)) should encompass this, i.e. self-service is allowed when operator scope is a superset of subject scope.

3. Issuance of certificates to external subjects

  • "External" means an subject that is not an IPA user, host or service. It could be some other object in the IPA directory (e.g. KDC krbtgt principal) or an object that exists outside IPA directory, e.g. a trusted realm principal, ACME client, etc.
  • Each kind of internal and external subject will have a particular way to validate the CSR and authorise the request. An example ACL requirement for smart cards might be, "users in group scadmins can issue certs from CA sc with profile sc to trusted realm principals whose principal name matches regex "...". The CSR validator for this use case would have to ensure that the subject exists and that Subject DN and alternative names match the subject.
  • We may also want to allow external principals as operator, e.g. allow a group of users from trusted AD realm to issue certs to themselves or certain IPA users/hosts/services or external subjects.
  • Additional concrete external subject use cases are sought, so that we can get this right!
  • This needs to be solved in a generic way that would work accross the framework, so that it can be reused for other parts of IPA where external users are relevant. Now that we allow AD users to log into IPA, there may be many cases.

A. Other suggested enhancements

  • Service groups
  • Only check if operator has write access to subject's userCertificate attribute if subject has such an attribute, and active profile is configured to store issued certificates.

Design ideas

Simo and Fraser discussed the following:

  • Moving validation (and possibly authorisation) logic to separate processes.
  • Benefits:
  • Programs can be written in whatever language makes sense
  • Programs can be more easily tested, independently of IPA framework
  • Where it makes sense programs can be delivered as separate packages or products, or customers can implement their own.
  • Configuration can be passed in environment and/or program args.
  • Moving validation and authorisation logic to Dogtag. Context:
  • Move more certificate handling logic to Dogtag plugins. (Specifically: plugins that invoke external processes, per previous point.)
  • This pattern has precedent in KeyRetriever interface and ExternalProcessKeyRetriever implementation, which are part of Dogtag and invoke the ipa-pki-retrieve-key program, which is part of FreeIPA.
  • Dogtag now (v4.4) has Kerberos principal which it can use to connect to IPA directory and read data for validating CSR, and read ACLs.
  • GSS-API support ( https://fedorahosted.org/freeipa/ticket/5011 ) would allow Dogtag to query LDAP with operator credentials, but using Dogtag principal may be saner from a debugging/support POV because LDAP permissions may vary among operators, leading to different/unpredictable results.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment