[16748] in Kerberos_V5_Development
Re: Delegation and Moonshot
daemon@ATHENA.MIT.EDU (Luke Howard)
Mon Apr 4 01:54:12 2011
In-Reply-To: <87mxk6myp3.fsf@windlord.stanford.edu>
Mime-Version: 1.0 (iPhone Mail 8G4)
Message-Id: <AF22567B-AD23-43A5-9BB3-B08EF0BA9B5E@padl.com>
From: Luke Howard <lukeh@padl.com>
Date: Mon, 4 Apr 2011 15:53:35 +1000
To: Russ Allbery <rra@stanford.edu>
Cc: Moonshot community list <moonshot-community@jiscmail.ac.uk>,
"krbdev@mit.edu" <krbdev@mit.edu>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Errors-To: krbdev-bounces@mit.edu
Russ,
With the example you give, you might be interested in an OpenLDAP ACL plugin we've developed that lets you use GSS attribute value assertions - eg from a SAML assertion - as authorization subjects.
-- Luke
Von meinem iPhone gesendet
Am 04/04/2011 um 14:23 schrieb Russ Allbery <rra@stanford.edu>:
> Nico Williams <nico@cryptonector.com> writes:
>
>> I don't mean to take anything away from this amazing work you've done,
>> but, credential delegation writ large is simply scary. Better to design
>> services that don't require it. For example, in the particular case you
>> mention of web gateways to mail services just trust the web service
>> fully and be done -- incredibly undesirable if the two services are not
>> run by the same organization, but then, would you really delgate access
>> to your mailboxes to a party other than the one that runs them?!
>
> Having done this for years, it does mostly work, but it has a serious
> drawback: it requires that you do authorization control at multiple
> levels. Properly managed delegation systems can instead allow you to do
> authorization control only once.
>
> The best way to see this is to consider LDAP as the final destination
> service. OpenLDAP, and probably other LDAP implementations, supports
> extremely complex access controls with many features, such as making
> access contingent on both the authenticating identity and on the values of
> other fields in the same object that one is trying to read fields from.
> We use those sorts of features here to implement user-chosen visibility.
> For example, may of our LDAP ACLs will release data if the corresponding
> suVisib attribute is set to stanford, but not if it's set to private;
> then, the data is only visible to specific privileged users or
> applications.
>
> If you have other software that uses LDAP to present information to a
> user, you now have to duplicate this extremely complex logic in every
> single application that may serve users with varying degrees of authorized
> access. If you want phone numbers to have user-settable privacy but
> always display them to Help Desk staff, for example, everything that
> displays phone numbers now has to look up the corresponding visibility
> settings and confirm that the current authenticated user has access based
> on those settings. If, however, you have delegated credentials, you can
> set the ACLs once on the LDAP servers and then everything just inherits
> them.
>
> The same issues do apply to services other than LDAP, in other ways, but
> they're the most obvious with LDAP.
>
>> Right, quite simple. BTW, do we want to be able to gss_store_cred()
>> impersonation credentials? I believe some will. E.g., if you need to
>> use secure NFS, AFS, ... as the client, then you have no way to pass the
>> desired credential handle to the NFS or AFS client. Being able to
>> create a PAG or keyring, or whatever, then store the credential there,
>> where the NFS or AFS client will find it, is a very good thing. Where
>> the impersonation credential is a Kerberos one this is already taken
>> care of. For other mechs it'll be something to think about.
>
> Yes. This is required to implement things like a web-based front-end to
> AFS. It is one of the main places we use delegation right now.
>
> --
> Russ Allbery (rra@stanford.edu) <http://www.eyrie.org/~eagle/>
> _______________________________________________
> krbdev mailing list krbdev@mit.edu
> https://mailman.mit.edu/mailman/listinfo/krbdev
_______________________________________________
krbdev mailing list krbdev@mit.edu
https://mailman.mit.edu/mailman/listinfo/krbdev
