On 11.1.2017 02:09, Fraser Tweedale wrote:
On Tue, Jan 10, 2017 at 10:48:08AM +0100, Martin Babinsky wrote:
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:
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
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:
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.
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.
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
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!
Manage your subscription for the Freeipa-devel mailing list:
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code