Authorization
Brian Garback
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?
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
Access Control
History
RBAC
CBAC
CAAC
PBDM
Role-Based Access Control
 Sandu et al. formalized Role-Based Access
Control in 1996
User
Role
Permission
 User U acting in role R is granted permission P


Advantage: greatly improved efficiency
Disadvantage: cannot specify fine-grained rules
Context-Based Access Control
 What is “context”?

Circumstances in which an event occurs
Subject
Object
Name
Age
ID
Location
Type
Owner
System
Time
Date
CPU Load
Context-Based Access Control
has
with
User
Role
given
Permission
Constraints
Context
 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
1.
2.
3.
U  S &&
P = P &&
C is evaluated as true under RC
CAAC Authorization Policy
S: user or role
has
Clause 1
condition
P: permission

 ……
……

given

C: constraint
Clause n
condition
context type
A predicate of
context
implementation
Evaluated by
2004 Security Infrastructure
Quick Review
assigned
 RBAC
User
granted
Role
assigned
 CBAC
User
Permission
has
Role
given
Permission
 CAAC:


dynamic specification and dynamic enforcement
of arbitrary access rules
separation of context implementation and the
main business logic of target applications.
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
1.
2.
3.
Backup of role
Decentralization of authority
Collaboration of work
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
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:
1.
2.
No delegation limitations (risky)
No role-hierarchy
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)
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.
2.
No admin delegation limitations (risky)
No role-hierarchy
PBDM1

Role-layers:
1.
2.
3.
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
1. John creates a DTR “D2”
2. John assigns


“change schedule” to D2
from PL’
“PE’” to D2
3. John assigns Jenny to D2
PBDM1 Revocation
 Individual user can:
1.
2.
Remove a user from delegatees
Remove parts from the delegation role
 Admin can:
1.
2.
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 multioption revocation features
PDBM2 Overview
 Four layers:
1.
2.
Regular roles (RR)
Fixed delegatable roles (FDBR)

3.
Temporal delegatable roles (TDBR)
 has no role hierarchy

4.
owns a set of DTRs which form a 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:

1.
2.
D3 created based on PL’ and delegated to QE’’
Create a delegation role D3
Assign:


3.
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’’
1. Create a delegation role D3
2. Assign:


permission change_schedule
to D3
FDBR PE’ to D3
3. Assign D3 to TDBR QE’’
PBDM2 Revocation
 Contains PBDM1’s security admin
 PBDM2 has options in the role layer:
1.
2.
3.
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:

Ambiguity btw admin
and delegation
 PBDM:


supports role and
permission level
delegation
Partial revocation is
also possible
Authorization
Specifications
WS-Policy
XACML
SAML
Policy Specification
 Security policies must be exchangeable across
domains
Hospital
Pharmacy
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:

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:
1.
2.
3.

Authentication
Attribute
Authorization decision
You can extend SAML to make your own kinds
of assertions
SAML conceptual model
Policy
Credentials
Collector
Policy
Authentication
Authority
Policy
Attribute
Authority
Policy Decision
Point
Attribute
Assertion
Authorization
Decision
Assertion
SAML
Authentication
Assertion
System
Entity
Application
Request
Policy Enforcement
Point
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-1203T10: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
Policy
Credentials
Collector
Policy
Authentication
Authority
Policy
Attribute
Authority
Policy Decision
Point
Attribute
Assertion
Authorization
Decision
Assertion
SAML
Authentication
Assertion
System
Entity
Application
Request
Policy Enforcement
Point
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
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