On Sat, 2015-04-18 at 17:39 +1000, Fraser Tweedale wrote: > On Fri, Apr 17, 2015 at 02:56:28PM -0400, Simo Sorce wrote: > > On Fri, 2015-04-17 at 14:08 +0200, Martin Kosek wrote: > > > On 04/16/2015 10:03 AM, Fraser Tweedale wrote: > > > > Hi everyone, > > > > > > > > Please review my Certificate Profiles design proposal: > > > > http://www.freeipa.org/page/V4/Certificate_Profiles > > > > > > > > Let me know what is unclear, what needs expansion, and what is plain > > > > wrong :) > > > > > > > > The schema for storing multiple certificates for a principal is > > > > still being discussed but I expect it will be agreed soon, and I > > > > will add it to the document. > > > > > > > > I am revising the sub-CAs design proposal and it will soon be > > > > published for review as well. > > > > > > 1) here did you get this feature template? It is the one that is obsolete > > > (header levels, document structure, missing author in the box)... This is > > > the > > > right template: > > > http://www.freeipa.org/page/Feature_template > > > > > > 2) I miss certprofile-find command - to enable Web UI and/or CLI to > > > search > > > through existing profiles. > > > > > > 3) Permissions > > > So your plan is to allow different groups use different profiles? So > > > there > > > would be for example profiles allowed to all users (something like > > > userCattegory:all that we use for HBAC/SUDO)? How do you plan to deal > > > with > > > authorization? Will be on a FreeIPA framework level or for example by DS > > > ACIs > > > that would simply not show the profiles? > > > > Keep in mind our design philosophy from the start was: the framework > > only have the privileges of the user accessing it and makes no ACI > > decisions. > > > > We broke that abstraction with the RA agent stuff, but I plan on fixing > > it some days by taking it away from the framework again, so I would not > > be favorable to see more Access control implemented in the framework > > unless there is no other sane way. > > > > Simo. > > > In regards to permissions, the plan is to have ACLs for declaring > which principals/groups can use which profiles on which (sub-)CA. > The `caacl' CLI commands[1] follow the form of hbacrule (although > with a unified `caacl-add-member' that handles different principal > types, rather than separate commands (similarly for removal). This > approach came from discussions with Honza. > > [1] > http://www.freeipa.org/page/V4/Sub-CAs#ipa_caacl-add_.3Cshortname.3E_.3Cacl.3E > > (These are in the sub-CAs design to kill two birds with one stone; > target CA and profile are two dimensions of the rule.) > > So... under the current design these access decisions would be made > by the IPA framework. > > There is another approach I can think of: an "ipa-auth" plugin for > Dogtag that is used by *all* IPA cert profiles. The ACL rules > themselves, the commands and the schema do not change at all, but > somehow the principal's credential is conveyed by IPA to Dogtag, and > Dogtag uses it to look back into the IPA directory and make the > authorization decision. This is probably more work than there is > time for, but it would be possible to move to it later. > > Can anyone think of other sane ways?
Either Dogtag directly or an agent is used in the middle, the framework performs the usual s4u2proxy and contact this agent/Dogtag on behalf of the user, this component applies Access control. This is what we do with LDAP, and we need to do that even more with the CA. Afaik currently Dogtag does not understand GSSAPI auth, but that is something we should probably add anyway eventually. If it is too much work to do it in dogtag, we can do it in a separate agent that the framework talk to. Privilege separation is important to keep, or a single fault in the framework will easily open the door to unlimited access to create certs, including subCAs, we need to be very careful there. Simo. -- Simo Sorce * Red Hat, Inc * New York -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
