[Freeipa-devel] using pyhbac for CA ACLs

[Jakub Hrozek]

On Mon, May 25, 2015 at 02:28:52PM +0300, Alexander Bokovoy wrote:
> On Mon, 25 May 2015, Martin Kosek wrote:
> >On 05/25/2015 09:35 AM, 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
> >>(https://fedorahosted.org/freeipa/ticket/5011).
> >>
> >>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 :)
> >
> >CCing Jakub as pyhbac is owned by SSSD to advise. I think pyhbac rule
> >evaluation could be hacked to do what you want to do, but IMO, we would be
> >really calling for trouble if we reuse an evaluation mechanism for HBAC for
> >different ACL (though similar in concept).
> No, it is just fine. The engine is abstracted away from the real
> knowledge of where the data comes in and really does very simple task
> that perfectly fitted for purpose here.

Right, the whole logic is contained here:
    https://git.fedorahosted.org/cgit/sssd.git/tree/src/providers/ipa/hbac_evaluator.c

What I wonder is if we should extend the API to provide a
certificate-specific function that would be pretty much just an alias for
an existing one to avoid overloading names and parameters? Or does it make
more sense to create a CA specific wrapper around pyhbac in the CA code?