Authorization
Download
1 / 54

Authorization - PowerPoint PPT Presentation


  • 234 Views
  • Updated On :

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

loader
I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
capcha
Download Presentation

PowerPoint Slideshow about 'Authorization' - daniel_millan


An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
Authorization l.jpg

Authorization

Brian Garback


Research issues l.jpg
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 l.jpg
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 l.jpg

Access Control History

RBAC

CBAC

CAAC

PBDM


Role based access control l.jpg
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 l.jpg
Context-Based Access Control

  • What is “context”?

    • Circumstances in which an event occurs

Subject

Object

System

Name

Age

ID

Location

Type

Owner

Time

Date

CPU Load


Context based access control7 l.jpg
Context-Based Access Control

has

given

with

  • Advantage: access control is context-aware

  • Disadvantage: this is still a static model

User

Role

Permission

Constraints

Context


Rbac cbac caac l.jpg
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 l.jpg
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 l.jpg
Definition 1: Context Type

A context typeis 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 l.jpg
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 l.jpg
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 l.jpg
Definition 4: Data Access

We define data accessas 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


Caac authorization policy l.jpg
CAAC Authorization Policy

has

given

C: constraint

P: permission

S: user or role

Clause n

Clause 1

……

……

condition

condition

context type

A predicate of

context

implementation

Evaluated by



Quick review l.jpg
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

User

Role

Permission

Constraints

Context


Permission based delegation model l.jpg
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


Delegation history l.jpg
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



Permission based delegation l.jpg
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


Pbdm0 rbdm l.jpg
PBDM0 > 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)


Permission based delegation22 l.jpg
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


Pbdm1 l.jpg
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


Pbdm1 example l.jpg
PBDM1 Example

  • John creates a DTR “D2”

  • John assigns

    • “change schedule” to D2 from PL’

    • “PE’” to D2

  • John assigns Jenny to D2


Pbdm1 revocation l.jpg
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


Pbdm2 pbdm1 l.jpg

0 & 1 cannot support role-to-role delegation

2 does with multi-step delegation and multi-option revocation features

PBDM2 > PBDM1


Pdbm2 overview l.jpg
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


Pdbm2 rules and example l.jpg
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’’


Pbdm2 architecture l.jpg
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’’


Pbdm2 revocation l.jpg
PBDM2 Revocation

  • Contains PBDM1’s 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


Pbdm comparison l.jpg
PBDM Comparison

  • RBDM:

    • Ambiguity btw admin and delegation

  • PBDM:

    • supports role and permission level delegation

    • Partial revocation is also possible


Authorization specifications l.jpg

Authorization Specifications

WS-Policy

XACML

SAML


Policy specification l.jpg
Policy Specification

  • Security policies must be exchangeable across domains

Hospital

Pharmacy

Send prescription

Policy response

Requested License

Prescription accepted


Policy specification34 l.jpg
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 l.jpg
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 l.jpg
CAAC Policy Specification

  • Our customized WS-Policy tags

    For any authorization policy AP = (S, P, C)


A sample policy l.jpg
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 l.jpg
XACML

  • OASIS standard version 1.1 (2.0 and 3.0)

  • Policy language

  • Access control decision request/response language


Xacml policies l.jpg
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 l.jpg
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 l.jpg
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.



Saml assertions l.jpg
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



Some common information in all assertions l.jpg
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 l.jpg
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 l.jpg
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 l.jpg
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 l.jpg
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 l.jpg
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 l.jpg
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>



Xacml saml l.jpg
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 l.jpg
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


ad