Authorization Brian Garback

Research Issues Authorization given who you are, what can you do? Authentication who are you? quantification of trust levels Mobile devices what capabilities do you have? can wireless be as secure as wired? Authorization given who you are, what can you do? how do we control privileges? Federation how can trust be shared? how to cross trust domain boundaries?

Itinerary History of Access Control Authorization Specifications Role-Based AC Context-Based AC Context-Aware AC Permission Based Delegation Model Authorization Specifications CAAC WS-Policy Implementation XACML SAML Specification-Level Goals

Access Control History RBAC CBAC CAAC PBDM

Role-Based Access Control Sandu et al. formalized Role-Based Access Control in 1996 User U acting in role R is granted permission P Advantage: greatly improved efficiency Disadvantage: cannot specify fine-grained rules User Role Permission

Context-Based Access Control What is “context”? Circumstances in which an event occurs Subject Object System Name Age ID Location Type Owner Time Date CPU Load

Context-Based Access Control has given with User Role Permission Constraints Context Before I begin to talk about our proposed solution, I’d like to give you some background on the prvious work that have been done in access control research area. Role based access control is the most popular access control model that is applied in current software systems. The most famous paper about RBAC was published by Sandu and et all in 1996. In that paper, they give the formal definition of RBAC model which contains 3 components: User, Role, Permission. The main idea of RBAC is to assign permissions to different roles instead of individual users. Since the number of roles in a system is much less the number of users, RBAC make access control not to be a big burden for administrators any more. But role is the only parameter that RBAC will take into consideration when making access control, administrators are not able to specify rules that are aware of other context information, such as time, location, trust level. Advantage: access control is context-aware Disadvantage: this is still a static model

RBAC → CBAC → CAAC RBAC and CBAC, even with extensions, cannot meet the access requirements of modern healthcare environments CAAC is an extension to CBAC that is consistent with implementation via web services CAAC permits dynamic specification and dynamic enforcement of arbitrary access rules Context implementation is separated from the main business logic of target applications.

Context-Aware Access Control Presented 2004 by Juhnze Hu Terminology: Data Object: the smallest unit to be accessed in an application Data Type: a group of data objects with the same attributes Data Set: the set of all data objects User Set: the set of potential entities that access the data objects

Definition 1: Context Type A context type is defined as a property related to every participant in an application when it is running. Context Set: a set of all context types in an application. CS = {CT1, CT2 … CTn}, 1  i  n. Context Implementation: a function of context types defined by CI: CT1 CT2  …  CTn  CT, n  0

Definition 2: Context Constraint We define a context constraint as a regular expression as follows: Context Constraint := Clause1  Clause2 …  Clausei Clause := Condition1  Condition2 …  Conditioni Condition := <CT> <OP> <VALUE> CT is an element of CS OP is a logical operator in set {>, , , , , =} VALUE is a specific value of CT

Definition 3: Authorization Policy An authorization policy as a triple, AP = (S, P, C) where: S: the subject in this policy, which could be a user or a role P: the permission in this policy, which is defined as a pair <M, O>, where M is an operation mode defined in {READ, APPEND, DELETE, UPDATE} and O is a data object or data type C: is a context constraint in this policy

Definition 4: Data Access We define data access as a triple, DA = (U, P, RC) where: U: a user in the User Set who issues this data access P: the permission this user wants to acquire RC: the runtime context, a set of values for every context type in the Context Set DA (U, P, RC) is granted iff there exists an AP (S, P, C) st U  S && P = P && C is evaluated as true under RC

CAAC Authorization Policy has given C: constraint S: user or role P: permission Clause 1  ……  Clause n condition  ……  condition context type A predicate of context implementation Evaluated by

2004 Security Infrastructure

Quick Review RBAC CBAC CAAC: assigned granted RBAC CBAC CAAC: dynamic specification and dynamic enforcement of arbitrary access rules separation of context implementation and the main business logic of target applications. User Role Permission assigned has given User Role Permission Constraints Context

Permission Based Delegation Model 2003: Zhang at GMU Given RBAC as an AC model Delegation of authority is common Need-to-know Separation of duty Rotation of sensitive job position Delegation involves Backup of role Decentralization of authority Collaboration of work

Delegation History RBDM0: human → human RDM2000: Delegator delegates role membership to a delegatee RDM2000: Role delegation in a role hierarchy and multi-step delegation Unit of delegation is a ROLE! PBDM Supports role and permission level delegation

RBDM Shortcomings

Permission Based Delegation PBDM0 Summary: Multi-step temporal delegation Two role types: Regular Roles (RR) Temporary Delegation Roles (DTR) Multi-step delegation and revocation Drawbacks: No delegation limitations (risky) No role-hierarchy

PBDM0 > RBDM John creates “D1” John assigns: permission “change_schedule” to D1 (permission-role) role “PE” to D1 (role-role) John assigns Jenny to D1 (user-role) P1 John creates a temporary delegation role “D1”. P2 John assigns the permission “change schedule” to D1 with permission-role assignment and role “PE” to D1 with role-role assignment. P3 John assigns Jenny to D1 with user-role assignment.

Permission Based Delegation PBDM0 Summary: Multi-step temporal delegation Two role types: Regular Roles (RR) Temporary Delegation Roles (DTR) Multi-step delegation and revocation Drawbacks: No admin delegation limitations (risky) No role-hierarchy

PBDM1 Role-layers: Each user has (RR, DBR) pair = RR in PBDM0 Regular Roles (RR) cannot be delegated to other roles or users Delegatable Roles (DBR) permissions can be delegated Delegation Roles (DTR) created by delegatable roles Each user has (RR, DBR) pair = RR in PBDM0 Solves admin issue: Administrative assignment of permissions to roles

PBDM1 Example John creates a DTR “D2” John assigns “change schedule” to D2 from PL’ “PE’” to D2 John assigns Jenny to D2

PBDM1 Revocation Individual user can: Admin can: Remove a user from delegatees Remove parts from the delegation role Admin can: Move permissions from DBR to RR Revoke a user from RR or DBR

PBDM2 > PBDM1 0 & 1 cannot support role-to-role delegation 2 does with multi-step delegation and multi-option revocation features Talk about role hierarchy and why this is not valid

PDBM2 Overview Four layers: RR and FDBR: Regular roles (RR) Fixed delegatable roles (FDBR) owns a set of DTRs which form a role hierarchy Temporal delegatable roles (TDBR) has no role hierarchy can receive permissions delegated by a FDBR (role-to-role deleg.) Delegation roles (DTR) owned by a FDBR RR and FDBR: the same as RR and DBR in PDBM1 have role hierarchies

PDBM2 Rules and Example Delegation authority handled by admin No individual user can own a DTR or permission Scenario: D3 created based on PL’ and delegated to QE’’ Create a delegation role D3 Assign: permission change_schedule to D3 FDBR PE’ to D3 Assign D3 to TDBR QE’’

PBDM2 Architecture D3 created based on PL’ and delegated to QE’’ Create a delegation role D3 Assign: permission change_schedule to D3 FDBR PE’ to D3 Assign D3 to TDBR QE’’

PBDM2 Revocation Contains PBDM1’s security admin PBDM2 has options in the role layer: Remove pieces of permissions from a delegation role Revoke a DTR owned by a FBDR Remove pieces of permissions from a FBDR to a RR

PBDM Comparison RBDM: PBDM: Ambiguity btw admin and delegation supports role and permission level delegation Partial revocation is also possible

Authorization Specifications WS-Policy XACML SAML

Prescription accepted Policy Specification Security policies must be exchangeable across domains Hospital Pharmacy Send prescription Policy response Need policies to be exchangeable and understandable across domains in case attributes need to be gathered from outside the domain. Requested License Prescription accepted

Policy Specification There are several XML-based policy languages WS-Policy (from Microsoft) XACML (eXtensible Access Control Markup Language) SAML (Security Assertion Markup Language) In CAAC, WS-Policy was chosen as the specification language because it is inherently supported in the Microsoft .NET framework.

WS-Policy Overview Why: Goal: What: To describe service requirements, preferences, and capabilities of web services Goal: Provide the general purpose model and syntax to describe and communicate the policies of a Web service What: Provides a flexible and extensible grammar for expressing the capabilities, requirements, and general characteristics of Web Services

CAAC Policy Specification Our customized WS-Policy tags For any authorization policy AP = (S, P, C) <wsa:DataType> specifies the data object or data type of permission P <wsa:AccessType> specifies the operation mode of permission P <wsa:Permission> specifies the permission P in an AP <wsse:SubjectToken> specifies the security token issued to S <wsse:ContextToken> specifies one context condition in C <wsse:ContextType> specifies which context type is used in one context condition of C

A Sample Policy <wsp:Policy> <wsp:AppliesTo> <wsa:EndpointReference> <wsa:DataType>PatientRecord</wsa:DataType> <wsa:AccessType>Delete</wsa:AccessType> <wsa:Permission>DeletePatientRecord</wsa:Permission> </wsa:EndpointReference> </wsp:AppliesTo> <wsse:SubjectToken wsp:Usage="Required"> <wsse:TokenType>Medical Records Staff</wsse:TokenType> </wsse:SubjectToken> <wsp:OneOrMore wsp:Usage="Required"> <wsp:All> <wsse:ContextToken wsp:Usage="wsp:GreatThan“ wsp:Preference="T(password)"> <wsse:ContextType>Trust Level</wsse:ContextType> </wsse:ContextToken> </wsp:All> </wsp:OneOrMore> </wsp:Policy>

XACML OASIS standard version 1.1 (2.0 and 3.0) Policy language Access control decision request/response language

XACML - Policies Policy Set: container of policies (local and remote) Policy: a set of rules Rule: a target, effect, and condition Target: a resource, subject, and action Effect: results of rule; “Permit” or “Deny” Condition: Boolean; “True,” “False,” or “Indeterminate”

XACML – Access Control Reconciles Multiple policies Multiple rules per policy Multiple control decisions Use a combining algorithm to combine multiple decisions into a single decision Use standard or customized algorithms Policy Combining Algorithms—used by PolicySet Rule Combining Algorithms—used by Policy

XACML – Policy Evaluation Obtain attributes from subject Compare obtained attributes with attributes accepted by the policy Evaluate conditions using standard or customized functions E.g. The function [type]-one-and-only looks in a “bag” of attribute values and returns the single value if there is one or an error if there are zero or multiple.

XACML Data Flow

SAML assertions An assertion is a declaration of facts about a subject SAML has three kinds, all related to security: Authentication Attribute Authorization decision You can extend SAML to make your own kinds of assertions

SAML conceptual model

Some common information in all assertions Issuer and issuance timestamp Assertion ID Subject Name plus the security domain Optional subject confirmation, e.g. public key “Conditions” under which assertion is valid SAML clients must reject assertions containing unsupported conditions Special kind of condition: assertion validity period Additional “advice” E.g., to explain how the assertion was made

Authentication assertion An issuing authority asserts that: subject S was authenticated by means M at time T Caution: Actually checking or revoking of credentials is not in scope for SAML! It merely lets you link back to acts of authentication that took place previously

Example authentication assertion <saml:Assertion MajorVersion=“1” MinorVersion=“0” AssertionID=“128.9.167.32.12345678” Issuer=“University of Virginia“ IssueInstant=“2003-12-03T10:02:00Z”> <saml:Conditions NotBefore=“2003-12-03T10:00:00Z” NotAfter=“2003-12-03T10:05:00Z” /> <saml:AuthenticationStatement AuthenticationMethod=“password” AuthenticationInstant=“2003-12-03T10:02:00Z”> <saml:Subject> <saml:NameIdentifier SecurityDomain=“virginia.edu” Name=“jim” /> </saml:Subject> </saml:AuthenticationStatement> </saml:Assertion>

Attribute assertion An issuing authority asserts that: subject S is associated with attributes A, B, C… with values “a”, “b”, “c”… Typically this would be gotten from an LDAP repository “jim” in “virginia.edu” is associated with attribute “Department” with value “Computer Science”

Example attribute assertion <saml:Assertion …> <saml:Conditions …/> <saml:AttributeStatement> <saml:Subject> <saml:NameIdentifier SecurityDomain=“virginia.edu” Name=“jim” /> </saml:Subject> <saml:Attribute AttributeName=“Department” AttributeNamespace=“http://virginia.edu”> <saml:AttributeValue> Computer Science </saml:AttributeValue> </saml:Attribute> </saml:AttributeStatement> </saml:Assertion>

Authorization decision assertion An issuing authority decides whether to grant the request: by subject S for access type A to resource R given evidence E The subject could be a human or a program The resource could be a web page or a web service, for example

Example authorization decision assertion <saml:Assertion …> <saml:Conditions …/> <saml:AuthorizationStatement Decision=“Permit” Resource=“http://www.amazon.com/purchase.htm”> <saml:Subject> <saml:NameIdentifier SecurityDomain=“virginia.edu” Name=“jim” /> </saml:Subject> </saml:AuthorizationStatement> </saml:Assertion>

SAML conceptual model

XACML & SAML XACML & SAML are counterparts E.g. XACML handles the access control policies and decisions SAML handles the actual communication of authentication and authorization requests and responses E.g. SAML used to assert authentication and authorization attributes XACML uses these assertions and evaluates the policies to come to a decision

Research Questions Dynamic interfaces per permission/role Permission management for subobjects Secondary role issues: Constrained hierarchical roles Permission-level constrained delegation Revocation Delegation extensions to XACML & SAML Provide an access control interface