[Freeipa-users] Certificate profiles and CA ACLs for service principals

[Fraser Tweedale]

On Tue, Mar 22, 2016 at 10:57:37PM +1100, earsdown wrote:
> Hi Fraser, Martin and Alexander,
> 
> Thanks for looking into this! For what it's worth, I think for this
> particular use case, I'm leaning more towards Alexander when he said:
> 
> >I don't think you need to group services this way. For managing
> >services, and this means being able to issue certificates/keytabs for
> >them, we have hosts. By default a host that a service belongs to is
> >capable to modify userCertificate attribute of the service already, so I
> >would expect it to be able to issue certificates with subject principal
> >corresponding to the service.
> 
> >If CAACL would follow the same logic by allowing hosts that manage
> >services to issue certificates with subject principals corresponding to
> >these services, that should be enough because, after all, these host
> >objects already have write permissions and can upload whatever
> >certificates they like to the service objects.
> >--
> >/ Alexander Bokovoy
> 
> Personally, I was very surprised when I discovered that, even though a host
> principal may manage a service principal, it is currently unable to request
> a certificate for that service principal if the service principal doesn't
> have specific access to the certificate profile, even though the host
> principal may have access to the same certificate profile. In my mind the CA
> ACL should be evaluated against the identity of the requestor, not the
> issuee. As long as the requestor is allowed to request on behalf of the
> issuee (achieved via the managedby attribute), then it should work. Now, if
> I used the credentials of the service principal directly (say, with a
> service keytab) to make the request (supposing the service principal wasn't
> listed in the CA ACL), then denying the request would be the expected
> behaviour (imo of course).
> 
> Okay, so even though Alexander's suggestion might be more intuitive,
> implementing service groups might be more feasible from a technical
> standpoint, and I'm fairly sure this use case would also be solved by
> implementing service groups. But, it would be painful without automember
> regexp rules, so please don't forget this :D
> 
> Cheers!
> 
The CA ACLs solve a different part of the authorisation puzzle for
certificates: what profiles (or, in the future, (sub-)CAs) may be
used to issue certs to a given subject is a different question from
which entities can request certificates on behalf of the subject.
Profiles which are allowed for a host principal (representing
physical or virtual machines) are not necessarily the same profiles
that should be used for service principals.  This is why CA ACLs
must be executed against the issuee principal.

It is best to implement service groups then support them in CA ACLs.

Final note: directory ACIs allow hosts to request certificates for
services they manage.  The overall authorisation for cert issuance
depends on *both* the directory ACIs and CA ACLs.

Cheers,
Fraser

> On 2016-03-22 20:50, Fraser Tweedale wrote:
> >On Tue, Mar 22, 2016 at 09:59:58AM +0100, Martin Kosek wrote:
> >>On 03/22/2016 05:55 AM, Fraser Tweedale wrote:
> >>> On Fri, Mar 18, 2016 at 08:12:44PM +1100, earsdown wrote:
> >>...
> >>> To my fellow FreeIPA developers: are service groups a sensible RFE?
> >>> Is there a reason why they have not been implemented?
> >>
> >>It *is* sensible RFE and it was actually already filed!
> >>
> >>https://fedorahosted.org/freeipa/ticket/5277
> >>
> >>Please feel free to add yourself to CC to receive updates or even help
> >>us with
> >>implementation.
> >>
> >>Thanks,
> >>Martin
> >>
> >Good to know... I've added myself to Cc and also filed an RFE for
> >enhancing CA ACLs with service groups once #5277 is implemented:
> >https://fedorahosted.org/freeipa/ticket/5753
> >
> >Cheers,
> >Fraser
> 
> -- 
> Manage your subscription for the Freeipa-users mailing list:
> https://www.redhat.com/mailman/listinfo/freeipa-users
> Go to http://freeipa.org for more info on the project