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 -- 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