Re: Federated realms and PAD
Simo Sorce <[email protected]>
| Newsgroups | gmane.ietf.krb-wg |
|---|---|
| Organization | Red Hat, Inc. |
| Message-ID | <[email protected]> |
On Thu, 2012-02-16 at 08:36 -0500, Sam Hartman wrote: > >>>>> "Nico" == Nico Williams <[email protected]> writes: > > Nico> so that it can get backed into scripts (I know, use $HOME). > Nico> And if we could rely on a global namespace, then I'd just drop > Nico> the URI thing. But I don't think we can, not in federated > Nico> realms that aren't remotely in the same "administrative > Nico> domain", which I thought was part of what the PAD was all > Nico> about. > > > So, I've been thinking about federated contexts a lot lately mostly for > ABFAB but certainly beyond that. When I explain why Kerberos is not > federated, one of the biggest things I cite is that Kerberos has > assumptions that bind it within one organization. Do you have a write-up of what these assumptions are ? > It's my understanding that the PAD has a very permissive trust > model. Obviously we haven't written it down yet, so this is still open. > However, it doesn't sound to me like the PAD intends to embrace > federated cross-organizational contexts. So, I think we can assume a > high degree of trust between PAD producers and consumers. That probably > influences some of these discussions somewhat. I am not sure the PAD itself is anything for/against federated cross-organizational contexts. It is a matter of how much code/policy decisions you want to put in your KDC filters. I think you could use the PAD in a federated scenario, but int that case you may end up generating on the KDC (or a dedicated service the KDC has access to) most of the contents of the PAD when the cross realm TGS is used and a ticket is requested. Simo. -- Simo Sorce * Red Hat, Inc * New York _______________________________________________ ietf-krb-wg mailing list [email protected] https://lists.anl.gov/mailman/listinfo/ietf-krb-wg