Authorization

1
Authorization

• Brian Garback

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

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

System
Subject
Object
Type Owner
Name Age ID Location
Time Date CPU Load
7
Context-Based Access Control
has
given
with
Role
User
Permission
Constraints
Context

• 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 ltCTgt ltOPgt ltVALUEgt
• CT is an element of CS
• OP is a logical operator in set gt, ?, ?, ?, ?,
  
• 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 ltM, Ogt, 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
given
has
C constraint
P permission
S user or role
Clause n
Clause 1

?
?

?
?
condition
condition
context type
A predicate of
context implementation
Evaluated by
15
2004 Security Infrastructure
16
Quick Review
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
Role
User
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
• 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 gt 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)

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
• 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
• 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 gt 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
• 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 PBDM1s 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
• Ambiguity btw admin and delegation
• PBDM
• supports role and permission level delegation
• Partial revocation is also possible

32
Authorization Specifications

• WS-Policy
• XACML
• SAML

33
Policy Specification

• Security policies must be exchangeable across
  domains

Hospital
Pharmacy
Send prescription
Policy response
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
• 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)

ltwsaDataTypegt specifies the data object or data type of permission P
ltwsaAccessTypegt specifies the operation mode of permission P
ltwsaPermissiongt specifies the permission P in an AP
ltwsseSubjectTokengt specifies the security token issued to S
ltwsseContextTokengt specifies one context condition in C
ltwsseContextTypegt specifies which context type is used in one context condition of C
37
A Sample Policy

• ltwspPolicygt
• ltwspAppliesTogt
• ltwsaEndpointReferencegt
• ltwsaDataTypegtPatientRecordlt/wsaDataType
  gt
• ltwsaAccessTypegtDeletelt/wsaAccessTypegt
• ltwsaPermissiongtDeletePatientRecordlt/wsa
  Permissiongt
• lt/wsaEndpointReferencegt
• lt/wspAppliesTogt
• ltwsseSubjectToken wspUsage"Required"gt
• ltwsseTokenTypegtMedical Records
  Stafflt/wsseTokenTypegt
• lt/wsseSubjectTokengt
• ltwspOneOrMore wspUsage"Required"gt
• ltwspAllgt
• ltwsseContextToken wspUsage"wspGreatThan
  wspPreference"T(password)"gt
• ltwsseContextTypegtTrust
  Levellt/wsseContextTypegt
• lt/wsseContextTokengt
• lt/wspAllgt
• lt/wspOneOrMoregt
• lt/wspPolicygt

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 Algorithmsused by PolicySet
• Rule Combining Algorithmsused 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

• ltsamlAssertion MajorVersion1
  MinorVersion0 AssertionID128.9.167.32.12345
  678 IssuerUniversity of Virginia
  IssueInstant2003-12-03T100200Zgt
  ltsamlConditions NotBefore2003-12-03T10000
  0Z NotAfter2003-12-03T100500Z /gt
  ltsamlAuthenticationStatement
  AuthenticationMethodpassword
  AuthenticationInstant2003-12-03T100200Zgt
  ltsamlSubjectgt ltsamlNameIdentifier
  SecurityDomainvirginia.edu Namejim
  /gt lt/samlSubjectgt lt/samlAuthenticationStat
  ementgt lt/samlAssertiongt

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

• ltsamlAssertion gt ltsamlConditions /gt
  ltsamlAttributeStatementgt ltsamlSubjectgt
  ltsamlNameIdentifier SecurityDomainvirg
  inia.edu Namejim /gt
  lt/samlSubjectgt ltsamlAttribute
  AttributeNameDepartment
  AttributeNamespacehttp//virginia.edugt
  ltsamlAttributeValuegt Computer Science
  lt/samlAttributeValuegt lt/samlAttributegt
  lt/samlAttributeStatementgtlt/samlAssertiongt

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

• ltsamlAssertion gt ltsamlConditions /gt
  ltsamlAuthorizationStatement
  DecisionPermit Resourcehttp//www.amazon.
  com/purchase.htmgt ltsamlSubjectgt
  ltsamlNameIdentifier SecurityDomainvirgi
  nia.edu Namejim /gt
  lt/samlSubjectgt lt/samlAuthorizationStatementgtlt
  /samlAssertiongt

52
SAML conceptual model
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