On Mon, 25 May 2015, Fraser Tweedale wrote:
Hi everyone,

CA ACLs (the forthcoming `caacl' plugin) will be used to declare
which users/hosts/services can get certificates from which CAs and
profiles.  For v4.2, we will enforce the ACLs in the framework; the
plan is to move ACL enforcement to Dogtag in a future release

I have written most of the caacl plugin and now I must update
cert-request to enforce the ACLs.  Using hbacrule as the guide, I
had a look at pyhbac and it seems to be a reasonable fit for
implementing this.  In particular:

- "targethost" and "service" correspond nicely to "(sub)CA" and
 "profile-id" for evaluation.

- A certificate request can be for a user, host or service; these
 will be overloaded into the pyhbac "user" concept.  But because we
 will always know who the requesting principal is, we will only
 ever need to deal with whatever of {user,host,service} the
 principal actually is, to be able to evaluate access.

- The "srchost" concept will be unused (therefore fixed to
 HBAC_CATEGORY_ALL).  Perhaps there could be some future use.

So, please provide feedback if you think this is a great idea or a
terrible idea :)
So, let me re-iterate. You want to define a set of rules, to be used in
'ipa cert-request' that would grant access to (sub)CA and profiles.
These rules would be managed with commands like
 ipa cert-request-allow-access 'subCa' 'profile' [--users|--hosts|--services]
 ipa cert-request-remove-access 'subCa' 'profile' [--users|--hosts|--services]

and internally 'ipa cert-request' would use HBAC engine from SSSD to
actually perform evaluation of the rules.

Is that right?
/ Alexander Bokovoy

Manage your subscription for the Freeipa-devel mailing list:
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code

Reply via email to