[14627] in Kerberos
Re: Principal naming.
daemon@ATHENA.MIT.EDU (Booker C. Bense)
Thu Jul 5 10:58:11 2001
Date: Thu, 5 Jul 2001 07:55:59 -0700 (PDT)
From: "Booker C. Bense" <bbense@networking.stanford.edu>
To: <asr@ufl.edu>
cc: <kerberos@mit.edu>
In-Reply-To: <200107051218.f65CIHX10516@smtp.ufl.edu>
Message-ID: <Pine.GSO.4.33.0107050732480.6419-100000@shred.stanford.edu>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
On Thu, 5 Jul 2001 asr@ufl.edu wrote:
>
>
> Greetings, all.
>
>
> We're re-examining how we name some special-purpose administrative principals
> here at UF, and wanted to evoke some comments or experiences.
>
> The docs seem clear that Kerberos 5 principals are:
>
>
> component(/component)+@REALM
>
> i.e. many components are possible.
>
- The documents are clear. The code is not so clear, I seem to recall
that there is some place where 3+ components breaks the code
( GSSAPI? )
>
> Has anyone encountered interoperability issues with more than two components?
- Microsoft does this with their kerberos implementation, but they
also provide two part aliases.
> What are the circumstances in which other organizations have used these longer
> principals?
- I vaguely remember that DCE at least allowed/encouraged this kind of
usage.
>
> We're contemplating using three segments to let us express:
>
>
> group1/APPLICATION/application-name
>
> to permit differentiation between the domain of application names and some
> other set of names we haven't thought of yet.
>
> We'd considered something like
>
> group_application/APPLICATION
>
> to parallel foo.bar.com/host
>
> but are currently thinking that, if we want to put in all three of those
> tokens we should use the '/' delimiter.
>
> Opinions?
>
- Well, in general I think you should have a damn good reason for
creating hierarchal name spaces. If you do you should think hard
and long about how to create those groups. Even then you will likely
get it wrong the first time. I know every project I've been on has
gotten it wrong in some way that wasn't clear until we had actual
experience with the system.
- The problem is that organizations change, but namespaces can't. It's
always possible to deepen a flat tree, but nearly impossible to
flatten an existing tree. My experience is that the best way to create
namespaces is to only divide things on functional bases. i.e. unless
there is something different in the kinds attributes and behaviours
all objects should be in the same bucket. However, this approach
directly conflicts with the realities of organizational politics, they
demand that functionally identical objects live in different
containers.
- Good Luck,
- Booker C. Bense
