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

[Fraser Tweedale]

On Mon, Feb 06, 2017 at 10:37:34AM +0200, Alexander Bokovoy wrote:
> On ma, 06 helmi 2017, Jan Cholasta wrote:
> > On 11.1.2017 02:09, Fraser Tweedale wrote:
> > > 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.
> > 
> > I don't like the prospect of having to bump DL every time a new
> > component is introduced. This time it might be OK, because the new DL is
> > apparently required for the RA -> GSSAPI change, but IMHO in general a
> > change in a certificate profile does not warrant a DL bump.
> > 
> > I agree that maintaining multiple versions of a profile is not the way
> > to go, but I think there are other options:
> > 
> > * Change `auth.instance_id` from `raCertAuth` to a new, IPA-specific
> > `ipaAuth`. Configure `auths.instance.ipaAuth` in CS.cfg to behave
> > exactly the same as `raCertAuth`. This will have to be done on all
> > masters, including old ones, which can receive the change in a bug fix
> > update (4.4.x). Then, on upgrade to new IPA with GSSAPI enabled Dogtag,
> > change `auths.instance.ipaAuth` to use external script for
> > authentication. Similar thing could be done for other profile
> > components.
> > 
> > * Do not care about old masters. Update the profile and let certificate
> > requests on old masters fail. This should be fine, as the situation
> > where there are different version masters should be only temporary until
> > all masters are upgraded. If an appropriate error is returned from
> > cert-request, automated requests via certmonger will be re-attempted and
> > will succeed once all masters are upgraded.
> I'd prefer an option number one. Using an IPA-specific auth instance
> would allow us to be more flexible in manipulating the properties of it
> in future without worrying to break older setups.
> 
This is essentially what will be accomplished with
ExternalProcessConstraint, which in FreeIPA profiles will be
configured to invoke a process that is shipped as part of FreeIPA.

Using an authentication plugin is not quite right because it will do
IPA-specific validation, not just authnz.

Cheers,
Fraser

> -- 
> / Alexander Bokovoy