[Freeipa-devel] KDC proxy implementation specs

[Nathaniel McCallum]

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