Delegation and Moonshot
lukeh at padl.com
Mon Apr 4 01:16:36 EDT 2011
If you want to pick apart the PAC, I would do it with the MIT libkrb5 plugin interface. See the code that already does that to some extent. If you want to process the picked apart PAC with policy to map it to UIDs, then either this interface or Shibboleth might be candidates.
Von meinem iPhone gesendet
Am 04/04/2011 um 14:48 schrieb Nico Williams <nico at cryptonector.com>:
> On Sun, Apr 3, 2011 at 11:38 PM, Luke Howard <lukeh at padl.com> wrote:
>>> winnowed according to policy at the AAA server. Is that possible?
>> Sure, or ditto at the KDC. Obviously, there's a convenience vs privacy tradeoff: the AAA server needs to include in the assertion any attributes that may be required by delegatees, and these will be visible to the delegating service. If this is unacceptable, a model where the KDC contacts the IdP is better.
> I thought about the KDC doing the winnowing, but surely the issuer of
> the assertion is best placed to do the winnowing, and if another party
> does it then the issuer has to trust it. Now, for attributes asserted
> by the KDC, sure, by my logic the KDC would have to do the winnowing.
>>> values that are of interest to the app (SIDs, ...) and even map them
>>> to other things that are locally meaningful (UIDs, GIDs, ...).
>> I think this could be better done with something like Shibboleth and mapping to the local (non-URN) namespace. We have this working with Moonshot and OpenSSH/OpenLDAP authorization and it works well.
> I guess it's time for me to take a deep dive into Shibboleth... But
> not anytime soon :(
> Can Shibboleth be made to pick apart the PAC?
>> That said, map to any is implemented by MIT. Not by Heimdal though.
> Think it can be made to handle the PAC cleanly?
More information about the krbdev