Home

SecPAL: Design and Semantics of a Decentralized Authorization Language

SecPAL: Design and Semantics of a Decentralized Authorization Language. Moritz Y. Becker; Andrew D. Gordon; Cédric Fournet. September 2006

We present a declarative authorization language. Policies and credentials are expressed using predicates defined by logical clauses, in the style of constraint logic programming. Access requests are mapped to logical authorization queries, consisting of predicates and constraints combined by conjunctions, disjunctions, and negations. Access is granted if the query succeeds against the current database of clauses. Predicates ascribe rights to particular principals, with flexible support for delegation and revocation. At the discretion of the delegator, delegated rights can be further delegated, either to a fixed depth, or arbitrarily deeply.

Our language strikes a fine balance between semantic simplicity, policy expressiveness, and execution efficiency. The semantics consists of just three deduction rules. The language can express many common policy idioms using constraints, controlled delegation, recursive predicates, and negated queries. We describe an execution strategy based on translation to Datalog with constraints and table-based resolution. We show that this execution strategy is sound, complete, and always terminates, despite recursion and negation, as long as simple syntactic conditions are met.

The SecPAL project lives here (MSR). The project aims are to develop a language for expressing decentralized authorization policies, and to investigate language design and semantics, as well as related algorithms and analysis techniques.

By Ehud Lamm at 2006-09-15 20:17 | DSL | Logic/Declarative | other blogs | 10086 reads

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.

Soutei

This sounds exactly like Oleg Kiselyov and Andrew Pimlott's Soutei. Perhaps Oleg can tell us more!

By Paul Snively at Fri, 2006-09-15 22:05 | login or register to post comments

SCOLLAR

This looks like it's related to the SCOLL language and SCOLLAR tool developed by Fred Spiessens. SCOLL was designed to allow reasoning both about capabilities and access control lists.

By Peter Van Roy at Sat, 2006-09-16 17:32 | login or register to post comments

Reminds me...

Reminds me of an access-control language developed for a (now defunct) product at a company I once worked for.

The system was basically for digital key management with functions for operations performed with keys. It made it easy to enforce digital key security for administrators. Users (which were really applications using an API) making requests to the system would present credentials (either password- or certificate-based) that would map to a group and role (as per traditional role-based access control). Resources in the system were represented as UNC paths, such as //root/signatureService/key/sign which would request the 'create digital signature' function for supplied data using the specified key.

Policies could be created in a special declarative language in whch each clause was a predicate:
user.certificate.DN.OU="Sales" or user.certificate.DN.OU="Marketing" and user.certificate.DN.O="Our Organisation";

If one predicate failed, the policy failed (access denied). Policies were mapped to resources (UNC paths). Delegation came from the group/role hierarchy the user enrolled into when making a request. It was all whizz-bang stuff, the engineers loved working on it.

The end result? No-one used it. The system came with the default policy (True) that always allowed access, and as far as I can tell, that was the only policy ever used. It was found to be much easier to control access by other means: trusted clients, firewalls, simple authentication, that sort of thing. My lesson learned? Keep it simple and practical. Make it easy to verify and trust your access control mechanisms, and push access control as close to the 'surface' of your system as possible.

I'm not saying there isn't a genuine need for something like SecPAL, however for most distributed systems, I'm skeptical a DSL is going to help where existing practical solutions, perhaps like Kerberos, already exist.

By simonhaines at Sun, 2006-09-17 03:54 | login or register to post comments