dcf2bdfb20
We introduce a notion of soft vs. hard aliases. Soft aliases are aliases of WELLKNOWN/REFERRALS/TARGET@$some_realm, where $some_realm is the realm we want the KDC to issue referrals to. Hard aliases are all other aliases, where if the client requested canonicalization then the KDC should update the names in the responses, or else if the client did not request canonicalization, then the KDC should treat the alias as a distinct principal with the same keys as the alias' canonical name. The logic for dealing with these is entirely located in the HDB backends. An HDB backend can implement hard aliases by replacing a found HDB_entry's principal with the name used to look it up. An HDB backend can implement soft aliases by returning HDB_ERR_WRONG_REALM to trigger the AS or TGS to return a referral. Currently only in-tree HDB backends support this feature that use _hdb_fetch_kvno() as their hdb_fetch_kvno() method implementation. That's all HDB backends other than SQLite3. Out-of-tree backends should be unaffected. We've added a decoration field to HDB_entry: aliased -- an int (boolean). This is only used internally in libhdb at this time. Out-of-tree HDB backends could have a use for this decoration, but we have not decided whether it is a public interface yet.
10 lines
376 B
Plaintext
10 lines
376 B
Plaintext
--sequence=HDB-extensions
|
|
--sequence=HDB-Ext-KeyRotation
|
|
--sequence=HDB-Ext-KeySet
|
|
--sequence=Keys
|
|
--decorate=HDB_entry:void:context?:::
|
|
# The `aliased` field is for indicating whether a name used in an HDB
|
|
# lookup was an alias. This could be useful to applications when hard
|
|
# aliasing is implemented in an HDB backend, as it should be.
|
|
--decorate=HDB_entry:int:aliased:::
|