Re: Google Docs as capabilities as data

Domenico Rotondi wrote:


è Attempting to prevent re-delegation is both futile and counterproductive.  It is futile because people can and do share credentials.  It is counterproductive because when they share credentials, you lose accountability.  Further, you force them to give up all their permissions in order to share a few of them.  I am now proposing that the Do Not Delegate flag be treated as a warning to indicate “Please do not delegate.”   In an enterprise setting, the employee will be informed that continuing with the delegation would violate policy and be given the chance to provide a justification for management.

Our delegation system doesn't force a subject to delegate all his/her rights. When you create a new token based on the one you own you can select which of the rights hou have (and for which you are also allowed to delegate) you actually grant to the other subject. Therefore if, for example, I have both read and write rights for resource X and I have the delegate right only for the read operation I can only grant you the read right to you creating a new token (actually the schema file we use supports also a delegation depth attribute, but this attribute is not currently accessible via the UI of our tool).

Sorry.  I didn’t make myself very clear.  Of course, any properly designed capability system, such as yours, will allow fine-grained, attenuated re-delegation.  However, if you  block re-delegation, people will share credentials.  That’s when they end up sharing all their rights.

Therefore we have a "can delegate" flag for each granted right. If you don't want a subject delegates received rights, simply don't set this flag in his/her capability token.
Regarding the sharing of credentials. We use X509 certificates and digital signatures to protect the tokens (and as a proof of ownership when submitting an access request). So users have to share their private keys if they want to share a capability.
We know this issue exists, but: first the owner of the X509 in any case remains accountable for his/her private key, and he/she's violating company policies (don't forget that the context of our system is to do access control to shop floor events in manufacturing).

If you do set that flag, people may not be able to get their jobs done.  When that happens, they will share their private keys, company policy notwithstanding.  Credential sharing in systems that make (re-)delegation hard is such a problem that Ping Identity runs a webinar on it.


è We have a PDP (Policy Decision Point) and a PEP (which actually is the Authorization Service of the pub/sub system). So each request is first locally checked by the Authorization Service (e.g., if the capability token is acceptable, the request is compliant to the capability token, ...); then the Authorizaiton Server asks the PDP for further checks (currently only if the capability token is reported as revoked or not).
We designed the Revocation Service to manage revocation requests and, if the revocation has to be performed, report this to the PDP and to the subject that reuqested the revocation (this "report" could be deferred in time due the decentralised nature of our system; so the Revocaiton Serivce/PDP could not have all the info for immediately taking a decision if a capability token must be revoked or not).

I just think it’s simpler to send the revocation request directly to the PDP.  (Actually,  the check is simple enough, you can even do it in the PEP.)

________________________
Alan Karp
Principal Scientist
Enterprise Services, Office of the CTO
Hewlett-Packard Company
1501 Page Mill Road
Palo Alto, CA 94304
(650) 857-3967, fax (650) 857-7029
http://www.hpl.hp.com/personal/Alan_Karp

_______________________________________________
cap-talk mailing list
[email protected]
http://www.eros-os.org/mailman/listinfo/cap-talk