Re: [Freeipa-devel] [DESIGN] Dogtag GSS-API Authentication
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 > wo
Re: [Freeipa-devel] [DESIGN] Dogtag GSS-API Authentication
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
Re: [Freeipa-devel] [DESIGN] Dogtag GSS-API Authentication
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. 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. Thanks, Fraser 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 response. 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
Re: [Freeipa-devel] [DESIGN] Dogtag GSS-API Authentication
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. > 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. > > > > Thanks, > > Fraser > > > > 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 > response. > 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! Cheers, Fraser -- 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
Re: [Freeipa-devel] [DESIGN] Dogtag GSS-API Authentication
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. 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. 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. 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. Thanks, Fraser 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 response. -- Martin^3 Babinsky -- 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
[Freeipa-devel] [DESIGN] Dogtag GSS-API Authentication
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 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, ???). Of course, any other general or specific feedback is welcome. Thanks, Fraser -- 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
