An alternative plan for principal mapping
srahul at novell.com
Thu Aug 3 05:53:30 EDT 2006
Sam Hartman wrote:
> I question whether it is true that adding an auxiliary class to a
> directory object should have the same semantic meaning as adding a
> link. I understand you believe the answer is yes. My best guess from
> a data modeling standpoint is that these operations have different
> semantic meaning: linking implies a more distant relationship. So it
> would be inappropriate for the plugin to treat them the same.
I think that adding an auxiliary class to a directory object has the
same semantic meaning as adding a link *from the KDC's point from view*
... not from the directory point of view.
From the KDC's point of view, if a user has two principals, they must be
handled uniformly. So, KDC should treat a user's principal created using
auxiliary class in the same way as a separate object linked to the user.
> Rahul> Hi,
> >> I don't see why the DAL plugin needs to handle links from
> >> kerberos principals to other objects. It seems better to move
> >> that handling into the code that understands the other objects
> >> and better understands the information model of the directory.
> >> Kerberos could at best maintain such links, but Kerberos is
> >> going to be no better at maintaining the links that something
> >> else. And if such links are useful, it is clear you have a
> >> something else.
> Rahul> A link between a Kerberos principal object and a directory
> Rahul> user object is needed for two reasons. 1. The KDC should
> Rahul> apply the user's login policies and password policies to
> Rahul> the principal. 2. When the principal authenticates to a
> Rahul> service, the service will use the link to find which user
> Rahul> the principal belongs to and grant appropriate access.
> Rahul> Since it is the KDC which needs the link (reason 1 above),
> Do reason 1 and 2 actually require the same type of link?
I think both 1 and 2 require the same type of link. Please explain why
you think otherwise.
> Also, I believe that Luke's question needs to be answered: how can we
> accomplish 1 in a portable manner?
Yes. We have to decide on how to do it. But I think the link will be
required (for the second principal on the user) immaterial of how we
decide to enforce the user's policy on the principal.
More information about the krbdev