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