[Freeipa-devel] design review: Certificate Profiles

[Fraser Tweedale]

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?

Regards,
Fraser

> > 4) Searching for certificates by profile - FEEDBACK REQUIRED
> > It would be nice to incorporate this filter to current cert-find command.
> > 
> > 5) Default set of profiles
> > Should we also propose a basic set of canned profiles so that I can picture 
> > what will be the possibilities?
> > 
> > Would it be something like
> > * Server profile
> > * Client profile
> > 
> > 6) Upgrades
> > It may happen that FreeIPA needs to upgrade defaults of a canned profile. It 
> > would be nice to have a section how it would do it.
> > 
> > This is all I could think of so far.
> > 
> 
> 
> -- 
> Simo Sorce * Red Hat, Inc * New York
>