Delegation and Moonshot

[Luke Howard]

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 at stanford.edu>:

> Nico Williams <nico at 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 at stanford.edu)             <http://www.eyrie.org/~eagle/>
> _______________________________________________
> krbdev mailing list             krbdev at mit.edu
> https://mailman.mit.edu/mailman/listinfo/krbdev