1. Authorization
Brian Garback

2. 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?

3. 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

4. Access Control History
RBAC
CBAC
CAAC
PBDM

5. 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

6. 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

7. 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 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

8. 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.

9. 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

10. 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

11. 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

12. 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

13. 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

14. 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

15. 2004 Security Infrastructure

16. 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

17. 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

18. 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

19. RBDM Shortcomings

20. 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

21. 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.

22. 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

23. 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

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

25. 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

26. 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

27. 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

28. 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’’

29. 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’’

30. 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

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

32. Authorization Specifications
WS-Policy
XACML
SAML

33. 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

34. 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.

35. 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

36. 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

37. 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>

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

39. 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”

40. 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

41. 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.

42. XACML Data Flow

43. 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

44. SAML conceptual model

45. 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

46. 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

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

48. 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”

49. 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=“ <saml:AttributeValue> Computer Science </saml:AttributeValue> </saml:Attribute> </saml:AttributeStatement> </saml:Assertion>

50. 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

51. Example authorization decision assertion
<saml:Assertion …> <saml:Conditions …/> <saml:AuthorizationStatement Decision=“Permit” Resource=“ <saml:Subject> <saml:NameIdentifier SecurityDomain=“virginia.edu” Name=“jim” /> </saml:Subject> </saml:AuthorizationStatement> </saml:Assertion>

52. SAML conceptual model

53. 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

54. 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