[29985] in Kerberos
Re: Principal attributes and policy in LDAP Realm
daemon@ATHENA.MIT.EDU (Ken Raeburn)
Wed Jun 18 09:05:33 2008
From: Ken Raeburn <raeburn@mit.edu>
To: Klaus Heinrich Kiwi <klausk@linux.vnet.ibm.com>
In-Reply-To: <1213703822.17827.61.camel@klausk.br.ibm.com>
Message-Id: <FB3E4173-062F-43F2-A570-7135D019012F@MIT.EDU>
Mime-Version: 1.0 (Apple Message framework v924)
Date: Wed, 18 Jun 2008 09:04:53 -0400
Cc: Kerberos mailing list list <kerberos@mit.edu>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Errors-To: kerberos-bounces@mit.edu
On Jun 17, 2008, at 07:57, Klaus Heinrich Kiwi wrote:
> On Mon, 2008-06-16 at 23:38 -0400, Ken Raeburn wrote:
>> I suspect there are several LDAP schemas we could do a better job of
>> supporting and integrating with...
>
> And what, in your opinion, would be the better approach to accomplish
> this task?
I don't think I'm familiar enough with LDAP in general and the various
schemas in particular to be well-qualified to answer that right now.
If the differences are minor, a single integrated back end with some
run-time configuration, as you suggest, would probably be best, but if
the differences in some of the schemas are too fundamental, it may not
be practical to support all the commonly-used ones out there with a
single database back end. Though at least some of the basic routines
for handling LDAP server config info and managing communication
channels can probably be kept common.
> What I am doing right now is using the existing KDB LDAP plugin as a
> base for a new plugin (I wonder if I should worry about namespace
> collisions later), but of course ideally we should stick with a single
> code base and have the differences handled by runtime configuration.
> I'm
> just not sure if that is feasible or not.
It sounds good to me, but I can't judge the feasibility at the moment
either.
Ken
________________________________________________
Kerberos mailing list Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos
