[Freeipa-devel] KDC proxy implementation specs

[Simo Sorce]

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