On Sun, Apr 3, 2011 at 11:23 PM, Russ Allbery <[log in to unmask]> wrote:
> Nico Williams <[log in to unmask]> 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.
In exchange you get one more thing to manage: credential delegation
policies. Such policies might be as simple as one more bit
per-principal (trusted-for-delegation), or quite complex if you want
to reduce attributes across delegation boundaries. One of the nice
things about a model like Smack is that you would be able to constrain
delegation in a simple way, requiring just one additional item
per-principal: a label (plus, when you need to create additional
labels, additional Smack rules, but hopefully you can manage to keep
those to a minimum).
> 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.
Oh, this is a very good example. I like it a lot, and I'll probably steal it :)
In the example I've used most often in the past (NFS), impersonation
is still used, but without credential delegation: you just trust the
service to impersonate anyone. This applies to LDAP too!
> The same issues do apply to services other than LDAP, in other ways, but
> they're the most obvious with LDAP.
I think it's the same problem in all cases. Not using credential
delegation does not mean not using impersonation.
>> 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.
Good to know.
Nico
--
|
