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