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

RBACCBACCAACPBDM

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

SystemSubject ObjectTypeOwner

NameAgeIDLocation

TimeDateCPU Load

Context-Based Access Control

RoleUser

Advantage: access control is context-aware Disadvantage: this is still a static model

Context

Permission Constraintswith has given

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) st1. U S &&2. P = P &&3. C is evaluated as true under RC

CAAC Authorization Policy

givenhasS: user or role

P: permission

C: constraint

Clause 1 Clause n……

condition

condition

……

context type

context

implementation

A predicate of

Evaluated by

2004 Security Infrastructure

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

RoleUser

Context

Permission Constraints

assigned has given

assigned granted

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 involves1. 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 hierarchy3. 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 D32. 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 D32. Assign:

permission change_schedule to D3

FDBR PE’ to D33. 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

Prescription accepted

Requested License

Policy response

Send prescription

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

2. Attribute

3. Authorization decision

You can extend SAML to make your own kinds of assertions

SAML conceptual model

SAML

AuthenticationAssertion

AttributeAssertion

AuthorizationDecisionAssertion

AuthenticationAuthority

AttributeAuthority

Policy DecisionPoint

Policy EnforcementPoint

Policy Policy Policy

Credentials Collector

System Entity

Application Request

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

SAML

AuthenticationAssertion

AttributeAssertion

AuthorizationDecisionAssertion

AuthenticationAuthority

AttributeAuthority

Policy DecisionPoint

Policy EnforcementPoint

Policy Policy Policy

Credentials Collector

System Entity

Application Request

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