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 System

Name Type Time
Age Owner Date
ID CPU Load
Location
Context-Based Access Control
with has given
User Role 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. U  S &&
2. P = P &&
3. C is evaluated as true under RC
CAAC Authorization Policy
has given
S: user or role P: permission C: constraint

Clause 1  ……  Clause n

condition  ……  condition

context type

A predicate of
context
implementation Evaluated by
2004 Security Infrastructure
 Quick Review
assigned granted
 RBAC User Role Permission

assigned has given

 CBAC User Role Permission Constraints

Context
 CAAC:
 dynamic specification and dynamic enforcement
of arbitrary access rules
 separation of context implementation and the
main business logic of target applications.
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
 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. No delegation limitations (risky)
2. 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. No admin delegation limitations (risky)
2. No role-hierarchy
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
 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. 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
 PBDM2 > PBDM1

 0 & 1 cannot support role-to-role delegation

 2 does with multi-step delegation and multi-
option revocation features
 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
 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’’
 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. 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
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
Send presc
r ip t io n

o l i c y r e sponse
P

Requested License

i p t i o n a c ce pted
Pre sc r
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
specifies which context type is used in one context
<wsse:ContextType>
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>
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. Authentication
2. Attribute
3. Authorization decision
 You can extend SAML to make your own
kinds of assertions
SAML conceptual model
Policy Policy Policy

Credentials Authentication Attribute Policy Decision

Collector Authority Authority Point

SAML
Authentication Attribute Authorization
Assertion Assertion Decision
Assertion

System Application
Policy Enforcement
Entity Request
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-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
Policy Policy Policy

Credentials Authentication Attribute Policy Decision

Collector Authority Authority Point

SAML
Authentication Attribute Authorization
Assertion Assertion Decision
Assertion

System Application
Policy Enforcement
Entity Request
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