2. Research Issues
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
Role-Based AC
Context-Based AC
Context-Aware AC
Permission Based Delegation Model
Authorization Specifications
CAAC WS-Policy Implementation
XACML
SAML
Specification-Level Goals
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
System
Subject Object
Type
Owner
Name
Age
ID
Location
Time
Date
CPU Load
7. Context-Based Access Control
Role
User
Advantage: access control is context-aware
Disadvantage: this is still a static model
Context
Permission Constraints
with has given
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
1. U S &&
2. P = P &&
3. C is evaluated as true under RC
14. CAAC Authorization Policy
given
has
S: user or role P: permission C: constraint
Clause 1 Clause n
……
condition condition
……
context type
context
implementation
A predicate of
Evaluated by
16. Quick Review
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
Role
User
Context
Permission Constraints
assigned has given
assigned granted
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
1. Backup of role
2. Decentralization of authority
3. Collaboration of work
18. Delegation History
RBDM0: human → human
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
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:
1. No delegation limitations (risky)
2. No role-hierarchy
21. PBDM0 > RBDM
1. John creates “D1”
2. John assigns:
permission
“change_schedule” to D1
(permission-role)
role “PE” to D1 (role-role)
3. John assigns Jenny to
D1 (user-role)
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:
1. No admin delegation limitations (risky)
2. No role-hierarchy
23. PBDM1
Role-layers:
1. Regular Roles (RR)
cannot be delegated to other roles or users
2. Delegatable Roles (DBR)
permissions can be delegated
3. 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
1. John creates a DTR “D2”
2. John assigns
“change schedule” to D2
from PL’
“PE’” to D2
3. John assigns Jenny to D2
25. PBDM1 Revocation
Individual user can:
1. Remove a user from delegatees
2. Remove parts from the delegation role
Admin can:
1. Move permissions from DBR to RR
2. 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
27. PDBM2 Overview
Four layers:
1. Regular roles (RR)
2. Fixed delegatable roles (FDBR)
owns a set of DTRs which form a role hierarchy
3. Temporal delegatable roles (TDBR)
has no role hierarchy
can receive permissions delegated by a FDBR (role-to-role deleg.)
4. 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’’
1. Create a delegation role D3
2. Assign:
permission change_schedule to D3
FDBR PE’ to D3
3. Assign D3 to TDBR QE’’
29. PBDM2 Architecture
D3 created based on PL’ and
delegated to QE’’
1. Create a delegation role D3
2. Assign:
permission change_schedule
to D3
FDBR PE’ to D3
3. Assign D3 to TDBR QE’’
30. PBDM2 Revocation
Contains PBDM1’s security admin
PBDM2 has options in the role layer:
1. Remove pieces of permissions from a
delegation role
2. Revoke a DTR owned by a FBDR
3. Remove pieces of permissions from a
FBDR to a RR
31. PBDM Comparison
RBDM:
Ambiguity btw admin
and delegation
PBDM:
supports role and
permission level
delegation
Partial revocation is
also possible
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:
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
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.
43. SAML assertions
An assertion is a declaration of facts about a
subject
SAML has three kinds, all related to security:
1. Authentication
2. Attribute
3. Authorization decision
You can extend SAML to make your own kinds
of assertions
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
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”
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
53. XACML & SAML
XACML & SAML are counterparts
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
