Delegation, Authorisation management and Delegent. Forwarded messagefrom Babak Sadighi.

[Anne Anderson <Anne.Anderson@Sun.COM>]

Babak has given me permission to forward this to the XACML TC.
It may be relevant to discussions of delegation in XACML.  By the
way, I know nothing more about this project than what is in this
e-mail.

-Anne

--- Begin Message ---

• From: Babak Sadighi <babak@sics.se>
• To: franks@mcs.anl.gov, polar@syr.edu, vwelch@ncsa.uiuc.edu,Anne.Anderson@Sun.COM
• Date: Wed, 03 Mar 2004 13:13:49 +0100

Hi,

We are a number pf researchers at Swedish Institute of Computer Science 
who have been working on authorisation management for a few years. We 
have now read through the discussions about Delegation and Policy 
Administration using XACML. It seems to us that the issues you are 
discussing is very similar to the type of work we have been doing. I 
here summarize what we have been doing and which results we have.

We have developed a formal framework for authorisation management and a 
calculus for that which we call Privilege Calculus which is originally 
given in [1]. In this framework we distinguish between what we call 
"access level permissions" and "Management (administration) authority" 
mainly for the same reasons that have been discussed in earlier emails 
by Frank Siebenlist in this email thread. The actual management activity 
in this framework is done by delegations. The type of delegation we use 
in this approach is not the same as the "speaks for" relation given by 
Abadi et. al. or the delegation type that is used in Trust Management 
approach such those developed by Blaze et.al. or SPKI or Delegation 
Logic by Li et.al. What we mean by delegation is the act of creating a 
privilege (either at the access level or at the management level), which 
is different from letting someone to enjoy a privilege that one has. In 
the first case, one may create a privilege for someone else without have 
the privilege by oneself or even being able to create that privilege for 
oneself. The distinction between the two types of delegations become 
much clearer when we consider revocations. Assume that Alice gives an 
access right to Bob to withdraw money from her account (a proxy right). 
When Bob tries to withdraw money from Alice's account, then he in fact 
speaks for Alice and he can prove that he has the right to speaks for 
her. If at later time, for some reason, Alice's right to access her 
account is revoked then Bob's right is automatically revoked. Another 
case would be when Alice is head of department and she creates access 
permissions for departments lecturer to read exam results stored in the 
department's database. If later Alice change position then her 
management authorities to create access rights to the department's 
database gets revoked, but this does not mean that Bob's (a lecturer at 
the department) access right, once given to him by Alice, gets 
necessarily revoked.

Further we have developed "constrained delegation mechanism" and a 
formal semantics for that in [2]. The constrained delegation mechanism 
is used to create delegation trees and to ensure that no one is able to 
delegate more than what he/she has the authority to do. The constrained 
delegation mechanism is incorporated in the Privilege Calculus framework.

In [3] we extend the framework with a number of revocation schemes. 
These schemes are simple, propagated and dominance revocations. The 
simple revocation is when only the creator of a privilege is empowered 
to revoke it, and no other privileges are affected by the revocation. 
The propagated is when revoking a privilege also revokes some other 
privileges that were supported by the first one in a delegation chain. 
The last scheme is about who has the authority to revoke a privilege. In 
some cases those authorities that have created management privileges 
that a delegation chain is stemming from needs to keep certain level of 
control, hence keep the authority to revoke privileges down in the chain.

At a certain time we looked at XACML and SAML to see if our type of 
delegation can be encoded in these formats and it did not seem to be 
straight forward. Hence the initiative in this group is very interesting 
for us and we would very much like to participate in this activity.

It is also important to point out that we have a C++ implementation of 
the calculus which is called Delegent. You find more information about 
Delegent on www.delegent.com. Delegent deals with authorisations and 
authorities given to groups of principals and also deals with set of 
actions and set of objects in its policy language. In [4], we describe 
how Delegent can be used as a middleware in .Net framework.

There is also a white paper on delegent which I can send you if you wish.
 
You can find more information on our group here:

www.sics.se/isl/pbr

[1]B. Sadighi Firozabadi, M. Sergot, and O. Bandmann. Using Authority 
Certificates to Create Management Structures 
<http://www.sics.se/isl/pbr/papers/SecurityProtocol01.ps>. In 
proceedings of Security Protocols, 9th International Workshop, 
Cambridge, UK, April 2001.

[2]Olav Bandmann, Mads Dam, and B. Sadighi Firozabadi. Constrained 
Delegations <http://www.sics.se/isl/pbr/papers/ConstraintDelegation.ps>. 
In proceedings of 2002 IEEE Symposium on Security and Privacy, 2002.

[3]B. Sadighi Firozabadi and M. Sergot. Revocation in the Privilege 
Calculus <http://www.sics.se/isl/pbr/papers/fast03.pdf>. In Proceedings 
of the 1st International Workshop on Formal Aspects in Security and 
Trust (FAST 2003), pages 39-51, September 2003.

[4]Erik Rissanen. Server based application level authorisation for rotor 
<http://www.sics.se/isl/pbr/papers/rotor03.pdf>. IEE Proceedings 
Software, 150(5):291-295, October 2003.

By the way, sorry to send this email directly to you, but I could not 
send it to the XACML list as we are not yet members.

Best regards,

Babak Sadighi

--- End Message ---

-- 
Anne H. Anderson             Email: Anne.Anderson@Sun.COM
Sun Microsystems Laboratories
1 Network Drive,UBUR02-311     Tel: 781/442-0928
Burlington, MA 01803-0902 USA  Fax: 781/442-1692