Return-Path: X-Original-To: apmail-directory-dev-archive@www.apache.org Delivered-To: apmail-directory-dev-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id E662018984 for ; Fri, 31 Jul 2015 06:45:42 +0000 (UTC) Received: (qmail 77128 invoked by uid 500); 31 Jul 2015 06:45:42 -0000 Delivered-To: apmail-directory-dev-archive@directory.apache.org Received: (qmail 77073 invoked by uid 500); 31 Jul 2015 06:45:42 -0000 Mailing-List: contact dev-help@directory.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: "Apache Directory Developers List" Delivered-To: mailing list dev@directory.apache.org Received: (qmail 77063 invoked by uid 99); 31 Jul 2015 06:45:42 -0000 Received: from mail-relay.apache.org (HELO mail-relay.apache.org) (140.211.11.15) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 31 Jul 2015 06:45:42 +0000 Received: from mail-io0-f177.google.com (mail-io0-f177.google.com [209.85.223.177]) by mail-relay.apache.org (ASF Mail Server at mail-relay.apache.org) with ESMTPSA id 6C16A1A022D for ; Fri, 31 Jul 2015 06:45:42 +0000 (UTC) Received: by ioii16 with SMTP id i16so76448766ioi.0 for ; Thu, 30 Jul 2015 23:45:41 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.107.131.91 with SMTP id f88mr1984564iod.190.1438325141718; Thu, 30 Jul 2015 23:45:41 -0700 (PDT) Received: by 10.36.31.204 with HTTP; Thu, 30 Jul 2015 23:45:41 -0700 (PDT) In-Reply-To: <8D5F7E3237B3ED47B84CF187BB17B66611BDD241@SHSMSX103.ccr.corp.intel.com> References: <8D5F7E3237B3ED47B84CF187BB17B66611BDD057@SHSMSX103.ccr.corp.intel.com> <8D5F7E3237B3ED47B84CF187BB17B66611BDD241@SHSMSX103.ccr.corp.intel.com> Date: Fri, 31 Jul 2015 14:45:41 +0800 Message-ID: Subject: Re: Leveraging Kerby Kerberos library in ApacheDS From: Kiran Ayyagari To: Apache Directory Developers List Content-Type: multipart/alternative; boundary=001a113ecd5624ccd3051c262b79 --001a113ecd5624ccd3051c262b79 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Fri, Jul 31, 2015 at 1:27 PM, Zheng, Kai wrote: > >> once Kerby is matured enough then we can add a dependency on it in > ApacheDS and integrate. > > Is there any good sign in your view for the maturity? It looks reasonable= , > but should we wait and do it then? I guess some pioneering work in Apache= DS > side would be tried first. > my point was only w.r.t standardizing the configuration and stick to one/two formats > > > >> The current code base tries to support way too many configuration > formats and I would like to see it support only one format, well and > complete. > > Well, kerby-config may attempt to support various formats, but in the > main/Kerberos part, only MIT format is used right now. I agree we may > support a =E2=80=98standard=E2=80=99 format if krb5.conf isn=E2=80=99t an= y good standard. In your > view, what=E2=80=99s left to be complete? Writing or generating of config= uration > file in a format? Or whatever? > I am totally fine with using krb5.conf and perhaps we can just stick to it, ignoring all other formats. I have only checked various implementations present in the code, not checked if they are in use so proposed to support an additional format. If we are already supporting krb5.conf then let us stick to it, and our effort can be diverted to other parts > > >> And then we can add a GUI config editor in Studio easily. > > Did you mean we need to generate a config file after some editing using > the GUI tool? Kerby-config module allows to load configuration items from= a > Java Map/Properties, which may work here. I mean, the edited values can b= e > stored in any form and then all the values can be loaded in a map for > config to use. > no, no, just mentioning that if we have one format writing a config editor becomes easier > > Regards, > > Kai > > > > *From:* Kiran Ayyagari [mailto:kayyagari@apache.org] > *Sent:* Friday, July 31, 2015 12:15 PM > *To:* Apache Directory Developers List > *Subject:* Re: Leveraging Kerby Kerberos library in ApacheDS > > > > > > > > On Fri, Jul 31, 2015 at 6:49 AM, Zheng, Kai wrote: > > Hi all, > > > > I=E2=80=99m thinking about what would be next steps after Kerby 1.0.0 out= . We > originally discussed when Kerby is ready, we=E2=80=99ll replace existing = Kerberos > related codes to simplify the code base in ApacheDS. This will include bo= th > the server and the studio. I thought this is important for the parent > project, IMHO, the code base with so many external dependencies is rather > complicated to move on (checking styles etc.), and also not easy to use. > For example, so many modules, just hard to figure out the combination whe= n > only need a part of it in my app. > > > > once Kerby is matured enough then we can add a dependency on it in > ApacheDS and integrate. > > > > The concern that I have at the moment is Kerby's configuration, The > current code base tries to support > way too many configuration formats and I would like to see it support > only one format, well and complete. > > I am fine if we plan to support MIT krb5.conf format in _addition_ to our > standard format > > but having more than these two formats slows us down. > > > > My personal preference would be to support JSON or YAML besides the > krb5.conf. And then we can add > a GUI config editor in Studio easily. > > > > Any thoughts? > > > > Regards, > > Kai > > > > > -- > > Kiran Ayyagari > http://keydap.com > --=20 Kiran Ayyagari http://keydap.com --001a113ecd5624ccd3051c262b79 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Fri, Jul 31, 2015 at 1:27 PM, Zheng, Kai <kai.zheng@intel.com= > wrote:

>> once Kerb= y is matured enough then we can add a dependency on it in ApacheDS and inte= grate.

Is there any good = sign in your view for the maturity? It looks reasonable, but should we wait= and do it then? I guess some pioneering work in ApacheDS side would be tried first.

my point was= only w.r.t standardizing the configuration and stick to one/two formats

=C2=A0

>> The curre= nt code base tries to support way too many configuration formats and I woul= d like to see it support only one format, well and complete.

Well, kerby-config= may attempt to support various formats, but in the main/Kerberos part, onl= y MIT format is used right now. I agree we may support a =E2=80=98standard= =E2=80=99 format if krb5.conf isn=E2=80=99t any good standard. In your view, what=E2= =80=99s left to be complete? Writing or generating of configuration file in= a format? Or whatever?

I am totall= y fine with using krb5.conf and perhaps we can just stick to it, ignoring a= ll other formats.
I have only checked various implementations= present in the code, not checked if they are in use
so propo= sed to support an additional format.

If we are= already supporting krb5.conf then let us stick to it, and our effort can b= e diverted to other parts


no,= no, just mentioning that if we have one format writing a config editor bec= omes easier

=

=C2=A0

Regards,

Kai<= /p>

=C2=A0

From: Kiran Ay= yagari [mailto:ka= yyagari@apache.org]
Sent: Friday, July 31, 2015 12:15 PM
To: Apache Directory Developers List
Subject: Re: Leveraging Kerby Kerberos library in ApacheDS=

=C2=A0

=C2=A0

=C2=A0

On Fri, Jul 31, 2015 at 6:49 AM, Zheng, Kai <kai.zheng@intel.com> wrote:

Hi all,

=C2=A0

I=E2=80=99m thinking about what would be next steps = after Kerby 1.0.0 out. We originally discussed when Kerby is ready, we=E2= =80=99ll replace existing Kerberos related codes to simplify the code base in ApacheDS. This will include both the server and the studio. I thou= ght this is important for the parent project, IMHO, the code base with so m= any external dependencies is rather complicated to move on (checking styles= etc.), and also not easy to use. For example, so many modules, just hard to figure out the combination when= only need a part of it in my app.

=C2=A0

once Kerby is matured enough then we can add a depen= dency on it in ApacheDS and integrate.

=C2=A0

The concern that I ha= ve at the moment is Kerby's configuration, The current code base tries = to support
=C2=A0way too many configuration formats and I would like to see it support= only one format, well and complete.

I am fine if we plan to support MIT krb5.conf format= in _addition_ to our standard format

but having more than these two formats slows us down= .

=C2=A0

My personal preference would be to support JSON or Y= AML besides the krb5.conf. And then we can add
=C2=A0a GUI config editor in Studio easily.

=C2=A0

Any thoughts?

=C2=A0

Regards,

Kai




--




--
Kiran Ayyagari
= http://keydap.com
--001a113ecd5624ccd3051c262b79--