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

[Alexander Bokovoy]

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. 

-- 
/ Alexander Bokovoy