1. New Challenges for Access Control April 27, 2005 1 Improving Usability and Expressiveness with Dynamic Policies and Obligations Dennis Kafura Markus Lorch Support provided by: Commonwealth Security Information Center Fermi National Accelerator Laboratory IBM

2. New Challenges for Access Control April 27, 2005 2 Organization  PRIMA – a privilege-based approach –Motivating Example –Models  Dynamic Policy –Model –Characteristics  Obligations –Use in PRIMA –XACML, PONDER, SAML

3. New Challenges for Access Control April 27, 2005 3 Motivating Example: Ad Hoc Collaboration Bob University Researcher “protocol emulator” “compute cluster“ Joan Corporate Reseacher “proprietary protocol” (2) request temp. permission Cluster Resource Protocol Emulator Admin (4) request service 1. assign privileges (3) relay created permission

4. New Challenges for Access Control April 27, 2005 4 Characteristics of Rights Management Access Rights Capabilities Privileges Dynamic Policy ACLs Rules Resource Policy Resource-centric Static (fixed assignment) Centralized administration Request-centric Dynamic (delegatable) Decentralized administration

5. New Challenges for Access Control April 27, 2005 5 PRIMA Models

6. New Challenges for Access Control April 27, 2005 6 Dynamic Policy Dynamic Policy: the set of validated rights presented with a specific service request. Discretionary creates distributed authority scaleable rights management Request-specific Enables least-privilege access Supports separation of duty

7. New Challenges for Access Control April 27, 2005 7 Obligations (in PRIMA)  Obligations provide additional instructions for and constraints on a decision  Can address mismatch in level of detail between request and policies  Can help maintain appl./system state while keeping PDP stateless and appl. independent

8. New Challenges for Access Control April 27, 2005 8 Obligation Use Case  PEP queries PDP for authZ decision on service request “Can subject X with role y perform action Z?”  Action Z may be a general type action, like execution of a compiled program  PDP has policies that govern exactly what files / memory and other system resources the subject X may access under role y  PDP thus replies with a “Yes, but” answer in the form of “Permit action Z, but only if the obligations localUsername=user01, rootPath=/tmp/data/user01, outgoingNetwork=no can be enforced.”

9. New Challenges for Access Control April 27, 2005 9 Obligation Support - XACML  In XACML Obligations are simple attribute assignments, e.g. rootPath=“/opt”, and semantics of these attributes have to be agreed upon  Obligations can be applied on a per-policy basis and are bound to the effect of the decision (permit or deny)  Standard XACML processing does not provide for the straight forward implementation on rule specific or conditional obligations  Obligations are rendered by the PEP (e.g., there is no attribute designator processing on PDP side for dynamic inclusion of information)

10. New Challenges for Access Control April 27, 2005 10 Obligation Support - Ponder  In Ponder a Policy consists of a single rule  A Policy that will convey an obligation is called a management or obligation policy  A Ponder obligation can be bound to any subject, not just the receiving PEP  A Ponder obligation describes the action that must be taken, of course actions need to be understood by the obligation holder

11. New Challenges for Access Control April 27, 2005 11 Obligation Support - SAML  SAML Authorization Decision Statements do not, by default, provide for obligations to be conveyed  In our work we implemented an “Obligated Authorization Decision Statement” that conveys one or more XACML Obligation constructs with a SAML decision.  New XACML-SAML-2 profile allows for the transmission of XACML decisions (incl. obligations) via SAML messages. No implementation yet (or?)

12. New Challenges for Access Control April 27, 2005 12 Use of Obligations in OSG  OpenScienceGrid effort, a large grid-computing project, uses obligated authorization decision statements (extended SAML statements)  Obligations convey parameters needed to configure the service / execution environment on the PEP before a requested service is rendered  Also allows the SAML AuthZ interface to be used for identity mapping (X500 DN to local uid, gid)  Policies can thus contain fine-grained instructions tailored to the service while the PDP stays application independent

13. New Challenges for Access Control April 27, 2005 13 Summary  Dynamic Policies improve the usability of the authorization system by incorporating the user as an integral part in discovering applicable policies for a specific request.  Obligations improve the expressiveness of authorization decisions by augmenting the boolean response with fine grained (enforcement) instructions.