[Freeipa-devel] Kerberos over HTTPS (KDC proxy)

[Simo Sorce]

On Thu, 2015-05-28 at 12:10 +0200, Petr Spacek wrote:
> On 28.5.2015 11:59, Martin Kosek wrote:
> > On 05/28/2015 11:12 AM, Alexander Bokovoy wrote:
> >> On Thu, 28 May 2015, Petr Spacek wrote:
> >>> On 28.5.2015 07:42, Jan Cholasta wrote:
> >>>> Dne 27.5.2015 v 15:54 Simo Sorce napsal(a):
> >>>>> On Wed, 2015-05-27 at 15:47 +0200, Jan Cholasta wrote:
> >>>>>> Dne 27.5.2015 v 15:43 Simo Sorce napsal(a):
> >>>>>>> On Wed, 2015-05-27 at 13:57 +0200, Jan Cholasta wrote:
> >>>>>>>>>>
> >>>>>>>>>>      ipa config-mod --enable-kdcproxy=TRUE
> >>>>>>>>>>      ipa config-mod --enable-kdcproxy=FALSE
> >>>>>>>>
> >>>>>>>> I don't like this approach, as it is completely inconsistent with
> >>>>>>>> every
> >>>>>>>> other optional component. There should be *one* way to handle them
> >>>>>>>> and
> >>>>>>>> there already is one, no need to reinvent the wheel.
> >>>>>>>
> >>>>>>> Sorry Jan, but this is really the correct approach.
> >>>>>>
> >>>>>> I don't think so.
> >>>>>>
> >>>>>>>
> >>>>>>> We want a boolean in LDAP to control whether the IPA Domain allows
> >>>>>>> proxying or not, the code is embedded in the overall framework and has
> >>>>>>> no need for explicit install/uninstall unlike the CA or DNS components.
> >>>>>>
> >>>>>> There is a boolean for every other component/service as well. If you
> >>>>>> want to add new API to manipulate the boolean, fine, but it should be
> >>>>>> done in a generic way that works for other components as well.
> >>>>>
> >>>>> This is the same as:
> >>>>> ipa config-mod --enable-migration=TRUE
> >>>>>
> >>>>> Why is it a problem ?
> >>>>
> >>>> This is a switch to enable the migrate-ds plugin. I think it's hardly fair to
> >>>> compare it to a whole new component which provides a new service to the
> >>>> outside world.
> >>>>
> >>>>> This is not a separate service.
> >>>>
> >>>> How is it not a separate service? If it's installed, MS-KKDCP is provided to
> >>>> the outside world, and if it's not installed MS-KKDCP is not provided to the
> >>>> outside world. How is this different from, say, DNS? (Besides implementation
> >>>> details, such as what protocols or how many daemons it uses - think about IPA
> >>>> as a black box for a moment.)
> >>>
> >>> I very much agree with Honza - we have per-replica boolean for every service
> >>> so there is no reason not to have one for kdc proxy, especially when we
> >>> consider future containerization of services.
> >> A mere 'me too' here. Note that once updates to RFC 4120 as outlined in
> >> https://tools.ietf.org/html/draft-mccallum-kitten-krb-service-discovery-00
> >> would be accepted, clients will not be assuming all of replicas serve
> >> MS-KKDCP proxies so there will not be need to run them everywhere.
> >> Rather, only the servers on a network boundary will need to be
> >> advertised. This means we'll eventually get per-replica need as well.
> >>
> >> It is fine to assume right now that all of them are going to run
> >> MS-KKDCP proxy but configuration isn't really going to be global.
> >>
> >> Additionally, ipa-kdcproxy-manage would need to manipulate
> >> _kerberos.$DOMAIN URI DNS records too, so there is more than just
> >> switching the boolean here.
> > 
> > I see. My question is - if we go this way, what is then the reasonable subset
> > configuration functionality realistic for FreeIPA 4.2 GA? (As we want this
> > feature in for 4.2). Is ipa-kdcproxy-manage doable?
> > 
> > What is the proposed API here?
> > 
> > ipa-kdcproxy-manage list
> > ipa-kdcproxy-manage enable <server>
> > ipa-kdcproxy-manage disable <server>
> 
> I believe that for 4.2 it is perfectly enough to have per-replica switch in
> LDAP (enabled by default) and to provide ldapmodify command in docs. User
> interface can be polished later if we get the design right.

For 4.2 is actually perfectly fine to have a global switch.

If someone wants to pick and choose they can disable the embedded proxy
and explicitly install one where they want.
Let's not complicate simple things please.

Later on, if we want, it will be simple enough to add per replica
switches which will be checked only if the proxy is globally enabled
with the current switch.

Simo.

-- 
Simo Sorce * Red Hat, Inc * New York