Dne 22.5.2015 v 12:24 Christian Heimes napsal(a):
Hello,

since May 1st I'm a new Red Hat employee and developer with the FreeIPA
team. Some of you may already recognize my name from my contributions to
CPython core, Python security and TLS/SSL improvements, or a couple of
PEPs. I'm very glad that I can now work on Open Source as a full time
job. I haven't had any dealings with FreeIPA before and just rudimentary
experience with LDAP and Kerberos as a developer. Over the past two
weeks I have been digging through FreeIPA sources, read docs and played
with its services. I'm slowly starting to grasp the building blocks.

I was put in charge of MS-KKDCP integration into FreeIPA 4.2 [1]. The
task is small and isolated enough for a new contributor. KKDCP stands
for Kerberos KDC proxy protocol. It was developed by Microsoft to tunnel
KDC requests over HTTPS. It's useful for firewalled environments where
88/TCP+UDP are blocked and only 80/TCP + 443/TCP are available. With
KKDCP the client side wraps each Kerberos request in an additional ASN.1
sequence and sends it as POST request to a proxy. The proxy unpacks the
request, forwards it to a KDC and returns its reply to the client. MIT
krb5 supports [2] KKDCP since 1.13, Fedora has backports for 1.12.

Nathaniel McCallum has written [3] a proxy server as WSGI app. I'm
working on improvements and integration of the WSGI app into FreeIPA.
Yesterday several bug fixes already landed in kdcproxy.

The integration into FreeIPA is the tricky part for me. I'm not familiar
enough with FreeIPA yet to understand possible implications, so I need
your guidance. I already got some feedback from several people (Dmitri,
Nathan, Nathaniel, Martin, Martin2, Petr, Alexander...).


Here is what I have so far:

1) The FreeIPA webui already depends on Apache and mod_wsgi. KDC proxy
will run from the same Apache HTTPD instance but it will use a different
mod_wsgi daemon configuration. A second WSGI daemon is easily configured
and allows us to tune the daemon for KDC proxy's needs. FreeIPA is
mounted at /ipa, KDC Proxy will be available at /KdcProxy or /kdc.

2) For now we are not going to introduce a separate package
freeipa-server-kdcproxy. freeipa-server will depend on python-kdcproxy
and install all configuration files. Therefore the entry point /KdcProxy
is always configured

3) An administrator must be able to enable/disable the new feature. The
state of the switch will be read when Apache is started or reloaded. The
feature must be configurable for each replica, too. A WSGI wrapper will
read the setting from ipaConfigString=enabledService in
cn=KDCPROXY,cn=$FQDN,cn=masters,cn=ipa,cn=etc. When the feature is
disabled, it will reply with 404 Not Found error.

4) In order to read the state of the switch, the WSGI script needs to be
able to connect to LDAP. I can use Apache's / FreeIPA webui's keytab to
get a ticket for GSSAPI bind. However Apache has no permission to read
ipaConfigStrings in the masters subtree. A new role/permission and ACI
is required here.

5) python-kdcproxy can read its configuration from multiple places. For
performance reasons we don't want DNS lookups. Therefore our proxy
instance will only use libkrb5.so to read a list of KDCs, kpasswd and
admin servers from /etc/krb5.conf.


Open questions / issues
-----------------------

For 3) and 4) the Apache HTTP principal must be able to read or at least
compare the state of the switch. The ACIs in the masters tree forbid any
access to ipaConfigString entries except for principals with 'System:
Read IPA Masters' permission. Martin Basti and Petr Spacek have
suggested that I introduce a new permission for the task. I haven't
figured out how to configure and assign a new permission. Right now my
experimental code uses this ACI:


(targetfilter="(ipaConfigString=enabledService)")(targetattr="ipaConfigString")(version
3.0; acl "Compare enabledService access to masters"; allow(search,
compare) userdn = "ldap:///all";;)

I think a "normal" ACI is fine, I'm not sure if it even should be a permission, given we have no service group object in IPA for use in roles. However, access should be limited only to HTTP on IPA servers.



I found ipaserver.install.service.Service and SimpleServiceInstance in
the FreeIPA sources. As far as I understand the use of the classes, they
are used in the installers to configure service instances. However the
kdcproxy service instance is going to be special. It has no 1:1 relation
to a system service. Instead it shares a system service (Apache HTTPD)
with the HttpInstance for FreeIPA's webui. AFAIK no other service
instance has such a relation.

Go ahead, it doesn't really matter there is no 1:1 relation to a system service. I don't think the services were supposed to have a 1:1 relation to system services in the first place. Notice how none of the older service names refer to a particular system service, but rather name what kind of service is provided (HTTP, DNS, CA, ...). It was only (relatively) recently that people started adding service entries for each system service. I believe it's wrong - for example, it does not make much sense to handle all of the DNSSEC related services separately from the DNS service.



Finally I haven't figured out the best way to configure the instance. An
admin should be able to enable / disable KDC proxy. Should I write a
script or a ipa plugin for the job?

A script, ipa-kdcproxy-install, if you want to be consistent with what's already there.



You can find my patch in my Github repos [4]. The installer code is
mostly untested, though.


Please advice :)
Christian


[1] https://www.freeipa.org/page/V4/KDC_Proxy
[2] http://web.mit.edu/kerberos/krb5-current/doc/admin/https.html
[3] https://github.com/npmccallum/kdcproxy
[4] https://github.com/tiran/freeipa/compare/master...kdcproxy2





--
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

Reply via email to