Authorization - PowerPoint PPT Presentation

View by Category
About This Presentation
Title:

Authorization

Description:

User U acting in role R is granted permission P. Advantage: greatly improved efficiency ... S: the subject in this policy, which could be a user or a role ... – PowerPoint PPT presentation

Number of Views:27
Avg rating:3.0/5.0
Slides: 55
Provided by: briang59
Category:

less

Write a Comment
User Comments (0)
Transcript and Presenter's Notes

Title: 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
About PowerShow.com