Re: [Freeipa-devel] KDC proxy implementation specs
On 2015-05-29 08:07, Nathaniel McCallum wrote: > On Fri, 2015-05-29 at 08:02 +0200, Jan Cholasta wrote: >> Dne 28.5.2015 v 16:48 Nathaniel McCallum napsal(a): >>> On Thu, 2015-05-28 at 16:34 +0200, Christian Heimes wrote: Jan has suggested to ipaConfigString=kdcProxyEnabled in cn=KDC,cn=$FQDN,cn=masters,cn=ipa,cn=etc instead of ipaConfigString=enabledService in cn=KDCPROXY,cn=$FQDN,cn=masters,cn=ipa,cn=etc. It makes sense to me. After all MS-KKDCP is just another transport for the KDC. [4] >>> >>> There may be a security concern here if we aren't careful. I think >>> I'm >>> in favor of KDCPROXY since it is a different application. >> >> What concern would that be? It has been already established that KDC >> proxy is not a different application, but rather a subcomponent of >> KDC >> in the other thread. > > Accidental exposure of something else in > cn=KDC,cn=$FQDN,cn=masters,cn=ipa,cn=etc. My fear comes from the fact > that in order to make this work we have to expose stuff in > cn=KDC,cn=$FQDN,cn=masters,cn=ipa,cn=etc to apache. These kind of cross > -domain security allowances always raises red flags for me. I don't need read permission for all ipaConfigString attributes. In fact search and compare for (ipaConfigString=kdcProxyEnabled) is just about enough. Of course I have to name the permission differently. But that is the least of my problems. :) Your key master, Christian signature.asc Description: OpenPGP digital signature -- 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] KDC proxy implementation specs
On Fri, 2015-05-29 at 08:11 +0200, Jan Cholasta wrote: > Dne 29.5.2015 v 08:07 Nathaniel McCallum napsal(a): > > On Fri, 2015-05-29 at 08:02 +0200, Jan Cholasta wrote: > > > Dne 28.5.2015 v 16:48 Nathaniel McCallum napsal(a): > > > > On Thu, 2015-05-28 at 16:34 +0200, Christian Heimes wrote: > > > > > Jan has suggested to ipaConfigString=kdcProxyEnabled in > > > > > cn=KDC,cn=$FQDN,cn=masters,cn=ipa,cn=etc instead of > > > > > ipaConfigString=enabledService in > > > > > cn=KDCPROXY,cn=$FQDN,cn=masters,cn=ipa,cn=etc. It makes sense > > > > > to > > > > > me. > > > > > After all MS-KKDCP is just another transport for the KDC. [4] > > > > > > > > There may be a security concern here if we aren't careful. I > > > > think > > > > I'm > > > > in favor of KDCPROXY since it is a different application. > > > > > > What concern would that be? It has been already established that > > > KDC > > > proxy is not a different application, but rather a subcomponent > > > of > > > KDC > > > in the other thread. > > > > Accidental exposure of something else in > > cn=KDC,cn=$FQDN,cn=masters,cn=ipa,cn=etc. My fear comes from the > > fact > > that in order to make this work we have to expose stuff in > > cn=KDC,cn=$FQDN,cn=masters,cn=ipa,cn=etc to apache. These kind of > > cross > > -domain security allowances always raises red flags for me. > > Well, the only exposed thing would be ipaConfigString, which always > has > an "enabledService" value for KDC and optionally would have > "kdcProxyEnabled" value if KDC proxy is enabled. IMO if someone wants > to > put something sensitive in there, they should use a different > attribute > anyway. So say we now. Then, five years from now, when this conversation is a distant memory (if that), someone will think it is a good idea to do something stupid. :) > > Don't cross the streams... it would be bad. :) > > Unless Zuul comes into the picture. Is Zuul the intern in 2020 that exposes bad stuff? Nathaniel -- 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] KDC proxy implementation specs
Dne 29.5.2015 v 08:07 Nathaniel McCallum napsal(a): On Fri, 2015-05-29 at 08:02 +0200, Jan Cholasta wrote: Dne 28.5.2015 v 16:48 Nathaniel McCallum napsal(a): On Thu, 2015-05-28 at 16:34 +0200, Christian Heimes wrote: Jan has suggested to ipaConfigString=kdcProxyEnabled in cn=KDC,cn=$FQDN,cn=masters,cn=ipa,cn=etc instead of ipaConfigString=enabledService in cn=KDCPROXY,cn=$FQDN,cn=masters,cn=ipa,cn=etc. It makes sense to me. After all MS-KKDCP is just another transport for the KDC. [4] There may be a security concern here if we aren't careful. I think I'm in favor of KDCPROXY since it is a different application. What concern would that be? It has been already established that KDC proxy is not a different application, but rather a subcomponent of KDC in the other thread. Accidental exposure of something else in cn=KDC,cn=$FQDN,cn=masters,cn=ipa,cn=etc. My fear comes from the fact that in order to make this work we have to expose stuff in cn=KDC,cn=$FQDN,cn=masters,cn=ipa,cn=etc to apache. These kind of cross -domain security allowances always raises red flags for me. Well, the only exposed thing would be ipaConfigString, which always has an "enabledService" value for KDC and optionally would have "kdcProxyEnabled" value if KDC proxy is enabled. IMO if someone wants to put something sensitive in there, they should use a different attribute anyway. Don't cross the streams... it would be bad. :) Unless Zuul comes into the picture. Nathaniel -- Jan Cholasta -- 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] KDC proxy implementation specs
On Fri, 2015-05-29 at 08:02 +0200, Jan Cholasta wrote: > Dne 28.5.2015 v 16:48 Nathaniel McCallum napsal(a): > > On Thu, 2015-05-28 at 16:34 +0200, Christian Heimes wrote: > > > Jan has suggested to ipaConfigString=kdcProxyEnabled in > > > cn=KDC,cn=$FQDN,cn=masters,cn=ipa,cn=etc instead of > > > ipaConfigString=enabledService in > > > cn=KDCPROXY,cn=$FQDN,cn=masters,cn=ipa,cn=etc. It makes sense to > > > me. > > > After all MS-KKDCP is just another transport for the KDC. [4] > > > > There may be a security concern here if we aren't careful. I think > > I'm > > in favor of KDCPROXY since it is a different application. > > What concern would that be? It has been already established that KDC > proxy is not a different application, but rather a subcomponent of > KDC > in the other thread. Accidental exposure of something else in cn=KDC,cn=$FQDN,cn=masters,cn=ipa,cn=etc. My fear comes from the fact that in order to make this work we have to expose stuff in cn=KDC,cn=$FQDN,cn=masters,cn=ipa,cn=etc to apache. These kind of cross -domain security allowances always raises red flags for me. Don't cross the streams... it would be bad. :) Nathaniel -- 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] KDC proxy implementation specs
Dne 28.5.2015 v 16:48 Nathaniel McCallum napsal(a): On Thu, 2015-05-28 at 16:34 +0200, Christian Heimes wrote: Jan has suggested to ipaConfigString=kdcProxyEnabled in cn=KDC,cn=$FQDN,cn=masters,cn=ipa,cn=etc instead of ipaConfigString=enabledService in cn=KDCPROXY,cn=$FQDN,cn=masters,cn=ipa,cn=etc. It makes sense to me. After all MS-KKDCP is just another transport for the KDC. [4] There may be a security concern here if we aren't careful. I think I'm in favor of KDCPROXY since it is a different application. What concern would that be? It has been already established that KDC proxy is not a different application, but rather a subcomponent of KDC in the other thread. -- Jan Cholasta -- 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] KDC proxy implementation specs
On Thu, 2015-05-28 at 17:13 +0200, Christian Heimes wrote: > On 2015-05-28 17:10, Simo Sorce wrote: > > On Thu, 2015-05-28 at 17:00 +0200, Christian Heimes wrote: > >> On 2015-05-28 16:53, Simo Sorce wrote: > >>> We can't have 2 different keytabs with the same principal name. > >>> If we need privilege separation we'll have to work on integrating > >>> GSS-Proxy and give the keytab only to GSS-Proxy leaving it off the hands > >>> of both the framework, the proxy, and apache itself. > >> > >> I had a different principal like KDCPROXY/fqdn@realm in mind. > >> > >>> Although to be honest I do not see why the proxy need access to the > >>> keytab at all, can we simply run it as a wsgi application under a > >>> different user and prevent it from accessing the apache keytab at all ? > >> > >> Yes, mod_wsgi is able to run a WSGI app as a different user: > >> > >> https://code.google.com/p/modwsgi/wiki/ConfigurationDirectives#WSGIDaemonProcess > >> > >> A different user needs another location for the ccache and perhaps > >> additional SELinux rules. > > > > If you are using the keytab only to acquire credentials to access ldap > > you could use a memory ccache and not have to deal with locations: > > KRB5CCNAME=MEMORY:kdcproxy_ > > Oh nice, I wasn't aware about the MEMORY scheme. Is that supported on > older versions of RHEL, too? Yes, it has been there for a long while. > >>> What do we need the keytab for ? > >>> Is it just in order to authenticate and read if the service is enabled ? > >>> Can we make that information available anonymously ? > >> > >> Yes, the information is not available for anon bind. It doesn't feel > >> right to disclose the settings to the public. > > > > Another option is to use ldapi and external auth, I forgot if we allow > > automatic binding for no-root users though. > > No, been there, tried it, failed. It works as root but not as Apache > user or my test user. Maybe we can enable it in cn=config, need to check what's needed, but it may be worth, if all you need is to read a few entries. Simo. -- Simo Sorce * Red Hat, Inc * New York -- 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] KDC proxy implementation specs
On 2015-05-28 17:10, Simo Sorce wrote: > On Thu, 2015-05-28 at 17:00 +0200, Christian Heimes wrote: >> On 2015-05-28 16:53, Simo Sorce wrote: >>> We can't have 2 different keytabs with the same principal name. >>> If we need privilege separation we'll have to work on integrating >>> GSS-Proxy and give the keytab only to GSS-Proxy leaving it off the hands >>> of both the framework, the proxy, and apache itself. >> >> I had a different principal like KDCPROXY/fqdn@realm in mind. >> >>> Although to be honest I do not see why the proxy need access to the >>> keytab at all, can we simply run it as a wsgi application under a >>> different user and prevent it from accessing the apache keytab at all ? >> >> Yes, mod_wsgi is able to run a WSGI app as a different user: >> >> https://code.google.com/p/modwsgi/wiki/ConfigurationDirectives#WSGIDaemonProcess >> >> A different user needs another location for the ccache and perhaps >> additional SELinux rules. > > If you are using the keytab only to acquire credentials to access ldap > you could use a memory ccache and not have to deal with locations: > KRB5CCNAME=MEMORY:kdcproxy_ Oh nice, I wasn't aware about the MEMORY scheme. Is that supported on older versions of RHEL, too? >>> What do we need the keytab for ? >>> Is it just in order to authenticate and read if the service is enabled ? >>> Can we make that information available anonymously ? >> >> Yes, the information is not available for anon bind. It doesn't feel >> right to disclose the settings to the public. > > Another option is to use ldapi and external auth, I forgot if we allow > automatic binding for no-root users though. No, been there, tried it, failed. It works as root but not as Apache user or my test user. Christian signature.asc Description: OpenPGP digital signature -- 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] KDC proxy implementation specs
Simo Sorce wrote: On Thu, 2015-05-28 at 17:00 +0200, Christian Heimes wrote: On 2015-05-28 16:53, Simo Sorce wrote: We can't have 2 different keytabs with the same principal name. If we need privilege separation we'll have to work on integrating GSS-Proxy and give the keytab only to GSS-Proxy leaving it off the hands of both the framework, the proxy, and apache itself. I had a different principal like KDCPROXY/fqdn@realm in mind. Although to be honest I do not see why the proxy need access to the keytab at all, can we simply run it as a wsgi application under a different user and prevent it from accessing the apache keytab at all ? Yes, mod_wsgi is able to run a WSGI app as a different user: https://code.google.com/p/modwsgi/wiki/ConfigurationDirectives#WSGIDaemonProcess A different user needs another location for the ccache and perhaps additional SELinux rules. If you are using the keytab only to acquire credentials to access ldap you could use a memory ccache and not have to deal with locations: KRB5CCNAME=MEMORY:kdcproxy_ What do we need the keytab for ? Is it just in order to authenticate and read if the service is enabled ? Can we make that information available anonymously ? Yes, the information is not available for anon bind. It doesn't feel right to disclose the settings to the public. Another option is to use ldapi and external auth, I forgot if we allow automatic binding for no-root users though. Rob, do you remember ? AFAIK we have no rules other than root -> DM. rob -- 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] KDC proxy implementation specs
On Thu, 2015-05-28 at 17:00 +0200, Christian Heimes wrote: > On 2015-05-28 16:53, Simo Sorce wrote: > > We can't have 2 different keytabs with the same principal name. > > If we need privilege separation we'll have to work on integrating > > GSS-Proxy and give the keytab only to GSS-Proxy leaving it off the hands > > of both the framework, the proxy, and apache itself. > > I had a different principal like KDCPROXY/fqdn@realm in mind. > > > Although to be honest I do not see why the proxy need access to the > > keytab at all, can we simply run it as a wsgi application under a > > different user and prevent it from accessing the apache keytab at all ? > > Yes, mod_wsgi is able to run a WSGI app as a different user: > > https://code.google.com/p/modwsgi/wiki/ConfigurationDirectives#WSGIDaemonProcess > > A different user needs another location for the ccache and perhaps > additional SELinux rules. If you are using the keytab only to acquire credentials to access ldap you could use a memory ccache and not have to deal with locations: KRB5CCNAME=MEMORY:kdcproxy_ > > What do we need the keytab for ? > > Is it just in order to authenticate and read if the service is enabled ? > > Can we make that information available anonymously ? > > Yes, the information is not available for anon bind. It doesn't feel > right to disclose the settings to the public. Another option is to use ldapi and external auth, I forgot if we allow automatic binding for no-root users though. Rob, do you remember ? Simo. -- Simo Sorce * Red Hat, Inc * New York -- 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] KDC proxy implementation specs
On Thu, 2015-05-28 at 17:07 +0200, Christian Heimes wrote: > On 2015-05-28 16:48, Nathaniel McCallum wrote: > > An apache module would also provide similar benefits. I'm not sure > > I > > necessarily want to stick with python here if we're optimizing for > > performance. Another option would be to add it to the KDC itself > > and > > proxy through Apache like we do for Tomcat. MIT might like that > > option. > > For that kind of network code Python is really fast enough. An event > driven framework like asyncio or Twisted can handle lots of > connections > simultaneous. We aren't speaking about several GBit/sec where zero > -copy > is required. > > I'm more worried about Apache than Python. Apache is tuned for the > needs > of the webui, e.g. prefork MPM. Let's see how it works out in a > production system. Right. And the KDC could just parse the messages directly. I agree. Let's wait and see. Nathaniel -- 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] KDC proxy implementation specs
On Thu, 2015-05-28 at 16:34 +0200, Christian Heimes wrote: > Hello, > > thanks you for your input. The former thread has 58 messages in > total. > Since last Friday we have came to an agreement in most points. I like > to > some up our decisions and focus on some minor details. > > decisions > - > > python-kdcproxy will be installed as a dependency of freeipa-server. > There won't be a separate freeipa-server-kdcproxy package. That may > or > may not change in the future. The decision is out of scope for 4.2.0. > [1] > > KDC proxy support will be enabled by default. The config files and > LDAP > settings will be created by ipa-server-install, ipa-server-upgrade > and > ipa-replica-install. > > The enabled/disabled switch will be stored per-replica in the > cn=masters,cn=ipa,cn=etc tree. An API and CLI tool for management is > postponed. [2] For now we settle for some doc examples that use the > ipa-ldap-updater as suggested by Alex. [3] > > > open for discussion > --- > > Jan has suggested to ipaConfigString=kdcProxyEnabled in > cn=KDC,cn=$FQDN,cn=masters,cn=ipa,cn=etc instead of > ipaConfigString=enabledService in > cn=KDCPROXY,cn=$FQDN,cn=masters,cn=ipa,cn=etc. It makes sense to me. > After all MS-KKDCP is just another transport for the KDC. [4] There may be a security concern here if we aren't careful. I think I'm in favor of KDCPROXY since it is a different application. > Martin Basti suggested a different keytab and principal for kdcproxy. > [5] The keytab is only required for GSSAPI bind to lookup the state > of > the enabled/disabled switch. The current patch uses the same keytab > as > webgui. > A new principal separates kdcproxy more cleanly and allows for > fine-grained ACIs. It is also more future proof. It may also have auditing benefits now that we are beginning to think about the A in FreeIPA. > In the future we may > want to move kdcproxy from an Apache WSGI app to a separate service. > A > dedicated Twisted or asyncio daemon could handle more load. > A separate keytab is easy to implement, too. I looked at the code in > HTTPInstance.__create_http_keytab(). An apache module would also provide similar benefits. I'm not sure I necessarily want to stick with python here if we're optimizing for performance. Another option would be to add it to the KDC itself and proxy through Apache like we do for Tomcat. MIT might like that option. > For the ACI I plan to add a new permission 'System: Read IPA Config > String' and make the principal a direct memberOf of it. We don't have > service roles yet. cn=roles,cn=accounts look like end user roles to > me. > The new ACI in cn=masters,cn=ipa,cn=etc will grant read, search and > compare permission: > > (targetfilter = "(objectClass=nsContainer)")(targetattr = "cn || > objectClass || ipaConfigString")(version 3.0; acl "Read IPA Config > String"; allow (read, search, compare) groupdn = "ldap:///cn=System: > Read IPA Config String,cn=permissions,cn=pbac,dc=ipa,dc=example";) > > > I should be able to modify and test my patch in a matter of a couple > of > hours. > > Christian > > [1] > http://www.redhat.com/archives/freeipa-devel/2015-May/msg00535.html > [2] > http://www.redhat.com/archives/freeipa-devel/2015-May/msg00555.html > [3] > http://www.redhat.com/archives/freeipa-devel/2015-May/msg00533.html > [4] > http://www.redhat.com/archives/freeipa-devel/2015-May/msg00543.html > [5] > http://www.redhat.com/archives/freeipa-devel/2015-May/msg00539.html > > -- > 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 -- 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] KDC proxy implementation specs
On 2015-05-28 16:48, Nathaniel McCallum wrote: > An apache module would also provide similar benefits. I'm not sure I > necessarily want to stick with python here if we're optimizing for > performance. Another option would be to add it to the KDC itself and > proxy through Apache like we do for Tomcat. MIT might like that option. For that kind of network code Python is really fast enough. An event driven framework like asyncio or Twisted can handle lots of connections simultaneous. We aren't speaking about several GBit/sec where zero-copy is required. I'm more worried about Apache than Python. Apache is tuned for the needs of the webui, e.g. prefork MPM. Let's see how it works out in a production system. Christian signature.asc Description: OpenPGP digital signature -- 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] KDC proxy implementation specs
On 2015-05-28 16:53, Simo Sorce wrote: > We can't have 2 different keytabs with the same principal name. > If we need privilege separation we'll have to work on integrating > GSS-Proxy and give the keytab only to GSS-Proxy leaving it off the hands > of both the framework, the proxy, and apache itself. I had a different principal like KDCPROXY/fqdn@realm in mind. > Although to be honest I do not see why the proxy need access to the > keytab at all, can we simply run it as a wsgi application under a > different user and prevent it from accessing the apache keytab at all ? Yes, mod_wsgi is able to run a WSGI app as a different user: https://code.google.com/p/modwsgi/wiki/ConfigurationDirectives#WSGIDaemonProcess A different user needs another location for the ccache and perhaps additional SELinux rules. > What do we need the keytab for ? > Is it just in order to authenticate and read if the service is enabled ? > Can we make that information available anonymously ? Yes, the information is not available for anon bind. It doesn't feel right to disclose the settings to the public. Christian signature.asc Description: OpenPGP digital signature -- 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] KDC proxy implementation specs
On Thu, 2015-05-28 at 10:48 -0400, Nathaniel McCallum wrote: > On Thu, 2015-05-28 at 16:34 +0200, Christian Heimes wrote: > > Hello, > > > > thanks you for your input. The former thread has 58 messages in > > total. > > Since last Friday we have came to an agreement in most points. I like > > to > > some up our decisions and focus on some minor details. > > > > decisions > > - > > > > python-kdcproxy will be installed as a dependency of freeipa-server. > > There won't be a separate freeipa-server-kdcproxy package. That may > > or > > may not change in the future. The decision is out of scope for 4.2.0. > > [1] > > > > KDC proxy support will be enabled by default. The config files and > > LDAP > > settings will be created by ipa-server-install, ipa-server-upgrade > > and > > ipa-replica-install. > > > > The enabled/disabled switch will be stored per-replica in the > > cn=masters,cn=ipa,cn=etc tree. An API and CLI tool for management is > > postponed. [2] For now we settle for some doc examples that use the > > ipa-ldap-updater as suggested by Alex. [3] > > > > > > open for discussion > > --- > > > > Jan has suggested to ipaConfigString=kdcProxyEnabled in > > cn=KDC,cn=$FQDN,cn=masters,cn=ipa,cn=etc instead of > > ipaConfigString=enabledService in > > cn=KDCPROXY,cn=$FQDN,cn=masters,cn=ipa,cn=etc. It makes sense to me. > > After all MS-KKDCP is just another transport for the KDC. [4] > > There may be a security concern here if we aren't careful. I think I'm > in favor of KDCPROXY since it is a different application. > > > Martin Basti suggested a different keytab and principal for kdcproxy. > > [5] The keytab is only required for GSSAPI bind to lookup the state > > of > > the enabled/disabled switch. The current patch uses the same keytab > > as > > webgui. > > A new principal separates kdcproxy more cleanly and allows for > > fine-grained ACIs. It is also more future proof. > > It may also have auditing benefits now that we are beginning to think > about the A in FreeIPA. We can't have 2 different keytabs with the same principal name. If we need privilege separation we'll have to work on integrating GSS-Proxy and give the keytab only to GSS-Proxy leaving it off the hands of both the framework, the proxy, and apache itself. Although to be honest I do not see why the proxy need access to the keytab at all, can we simply run it as a wsgi application under a different user and prevent it from accessing the apache keytab at all ? > > In the future we may > > want to move kdcproxy from an Apache WSGI app to a separate service. > > A > > dedicated Twisted or asyncio daemon could handle more load. > > A separate keytab is easy to implement, too. I looked at the code in > > HTTPInstance.__create_http_keytab(). > > An apache module would also provide similar benefits. I'm not sure I > necessarily want to stick with python here if we're optimizing for > performance. Another option would be to add it to the KDC itself and > proxy through Apache like we do for Tomcat. MIT might like that option. What do we need the keytab for ? Is it just in order to authenticate and read if the service is enabled ? Can we make that information available anonymously ? > > For the ACI I plan to add a new permission 'System: Read IPA Config > > String' and make the principal a direct memberOf of it. We don't have > > service roles yet. cn=roles,cn=accounts look like end user roles to > > me. > > The new ACI in cn=masters,cn=ipa,cn=etc will grant read, search and > > compare permission: > > > > (targetfilter = "(objectClass=nsContainer)")(targetattr = "cn || > > objectClass || ipaConfigString")(version 3.0; acl "Read IPA Config > > String"; allow (read, search, compare) groupdn = "ldap:///cn=System: > > Read IPA Config String,cn=permissions,cn=pbac,dc=ipa,dc=example";) > > > > > > I should be able to modify and test my patch in a matter of a couple > > of > > hours. > > > > Christian > > > > [1] > > http://www.redhat.com/archives/freeipa-devel/2015-May/msg00535.html > > [2] > > http://www.redhat.com/archives/freeipa-devel/2015-May/msg00555.html > > [3] > > http://www.redhat.com/archives/freeipa-devel/2015-May/msg00533.html > > [4] > > http://www.redhat.com/archives/freeipa-devel/2015-May/msg00543.html > > [5] > > http://www.redhat.com/archives/freeipa-devel/2015-May/msg00539.html > > > > -- > > 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 > -- Simo Sorce * Red Hat, Inc * New York -- 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
