[Freeipa-devel] [DESIGN] Dogtag GSS-API Authentication

[Fraser Tweedale]

On Tue, Jan 10, 2017 at 10:48:08AM +0100, Martin Babinsky wrote:
> Hi Fraser,
> 
> I have some rather inane comments. I guess Jan cholasta will do a more
> thorough review of your design. See below:
> 
> On 01/06/2017 09:08 AM, Fraser Tweedale wrote:
> > Hi comrades,
> > 
> > I have written up the high-level details of the FreeIPA->Dogtag
> > GSS-API authentication design.  The goal is improve security by
> > removing an egregious privilege separation violation: the RA Agent
> > cert.
> > 
> > There is a fair bit of work still to do on the Dogtag side but
> > things are shaping up there and it's time to work out the IPA
> > aspects.  The design is at:
> > 
> >   http://www.freeipa.org/page/V4/Dogtag_GSS-API_Authentication
> 
> first of all, you link a internal document from publicly available design
> page. you should prepare a publicly visible version of the Dogtag-side
> design and link that.
> 
Will do; thanks.

> It would also be nice to have a high-level graphical representation of the
> proposed CSR processing workflow. I think you can re-use the one that is in
> the Dogtag part, omit the Dogtag internals and add IPA-specific parts.
> 
I will definitely do this a bit later, once more details of IPA
design are established.

> > 
> > Right now, I need feedback about the Domain Level aspects: whether
> > it is the right approach, whether there are mechanisms to perform
> > update steps (specifically: LDAP updates and/or api calls) alongside
> > a DL bump, or if there aren't, how to deal with that (implement such
> > a mechanism, make admins do extra steps, ???).
> > 
> 
> Is the DL bump really necessary? Are you sure we really can not just update
> the profile configuration and let older Dogtag installation handle it
> gracefully? IIRC we have done some profile inclusion work in 4.2 development
> and on and never really bothered about older Dogtag understanding them.
> 
The problem is that the new profiles will refer to plugins (i.e.
classes) that do not exist in older versions of Dogtag.  Profile
config is replicated, so if we upgrade profile config with old
versions of Dogtag in the topology, it breaks them.

I considered a mechanism where multiple versions of a profile exist
in LDAP (i.e. multiple attribute values), and Dogtag picks the one
that's "right" for it.  (An example of how to do this might be
attribute tagging where tag indicates minimum version of Dogtag
containing components used in that profile version, and Dogag picks
the highest that it supports).  The advantage of such a mechanism is
that we could use it for any future scenario where we introduce new
profile components that we want to use in IPA.  The downside is that
it significantly complicates profile management (including for
administrators), and can result in the same profile having different
behaviour on different Dogtag instances, which could be confusing
and make it harder to diagnose issues.  Given the tradeoffs, I think
a DL bump is preferable.

> Anyway I guess we can call `certprofile-import' to load
> ExternalProcessConstraint-enabled profile upon setting domain level to 2, we
> just have to know where on the FS it is located.
> 
> > Of course, any other general or specific feedback is welcome.
> > 
> > Thanks,
> > Fraser
> > 
> 
> So if I understand correctly there will be no change in CA ACL management
> interface and only the code which evaluates them will be factored out into
> 'ipa-pki-validate-cert-request' command? Also, wouldn't it simpler if the CA
> ACL evaluation was delegated to a separate API command instead?
> ExternalProcessConstraint would then only ask IPA JSON api and process the
> response.
> 
There are no changes to CA ACL management interface as part of this
design, but there are proposals to extend/rework it in future, e.g.
#6424, #6425, #6426.

Having a separate command for CA ACL evaluation is a good idea, and
a clean refactoring target.  ExternalProcessConstraint is generic
with no knowledge of IPA API, but 'pki-pki-validate-cert-request'
can invoke the new API command.

Thanks for your feedback, Martin!

Cheers,
Fraser