Re: choosing principal names

On Thu, Oct 6, 2011 at 9:55 AM, Booker Bense <[email protected]> wrote:
> On Thu, 6 Oct 2011, [email protected] wrote:
>> Oh yes PAC, it is a way to use Kerberos to deliver more of verified data
>> than the mere principal name.
>>
>> May be it is what Booker Bense meant as an alternative to using
>> principal names for making authorization desicions.
>>
>
> Not at all, GSSAPI et al are just stop gap measures in which it is
> impossible to write a complete application. Just like kerberos
> provides a centralized authentication service, you need a centralized
> authorization and naming service. In an ideal
> world principals would simply be uuid's that provide a key
> to retrieving authorization and naming data. In the current world, using the

The GSS-API doesn't make it hard to do that.  You could have
completely meaningless principal names and local name-based ACLs
everywhere.

The problem is the need to distribute authorization data -- it's the
/etc/hosts problem all over again.

> principal as a key to perform an LDAP lookup
> is about as close as you can feasibly get. Embedding that ldap
> lookup in a PAC is just a performance hack.

It's a very good performance optimization, first of all, but also it's
good for privacy: the issuer can change the PAC contents according not
just to who is the client principal, but also according to who is the
service principal (or what realm you transit to/through).  And this
can be different from what LDAP (or whatever) might say.  Indeed, this
is why RedHat is pursuing a "PAD".

> Until DCE is eventually reinvented in a form that actually works,
> there will continue to be a mishmash of hacks to bridge the missing pieces.
> Adding meaning to principal names simply encourages the same bad design,
> pretending they are content-free
> keys will at least move you in the correct direction.

I submit that the two fundamental problems in authorization are: a)
how to distribute authorization data while protecting privacy, b) how
to handle OS differences (e.g., Unix has UIDs and GIDs, Windows has
SIDs) and also how to deliver attributes that don't easily fit the
user/group mold.

As for adding meaning to principal names, in the case of service
discovery that is actually a very simple way to make authorization
easier.  In other cases it's not at all easier and often harder (e.g.,
the NFS root-equiv case).

> I get the point of the poor admin trying to actually build
> a working system with this stuff, but at some point you just
> have to accept that it's got limitations and move on.

Agreed.

Nico
--