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