21 june 2006copyright 2006 university of kent1 delegation of authority (dyvose project) david...

23
21 June 2006 Copyright 2006 University of Kent 1 Delegation of Authority (DyVOSE project) David Chadwick University of Kent

Post on 21-Dec-2015

214 views

Category:

Documents


0 download

TRANSCRIPT

21 June 2006 Copyright 2006 University of Kent 1

Delegation of Authority(DyVOSE project)

David Chadwick

University of Kent

21 June 2006 Copyright 2006 University of Kent 2

What is Delegation of Authority?

• Allowing someone to act on your behalf to perform tasks (consume resources) that are available to you

• Delegator should be empowered to delegate to anyone he needs to, subject to certain organisation controls (i.e. the organisation’s Delegation Policy)

21 June 2006 Copyright 2006 University of Kent 3

How do you delegate to others today?

• To enter your house and fetch something– If your house if locked?

• To use your PC – If it is protected by a username and

password?

• To withdraw money from your bank account – Using an ATM?

21 June 2006 Copyright 2006 University of Kent 4

What is the problem with these existing delegation mechanisms?

• The other person usually masquerades as you, or impersonates you

• There is no control on what they can do– Anything you can do, they can do

21 June 2006 Copyright 2006 University of Kent 5

What is a better solution?

• The delegate should act in his own name, not in yours– Then a full audit trail can be kept of who did

what

• The delegate should have limited authority– So that you can delegate a fraction of your

powers

21 June 2006 Copyright 2006 University of Kent 6

ResourceOwner

“I authorise this Privilege Holder to use this resource in the following ways”signed The Resource Owner

Privilege Holder

“I delegate authority to this End User to use this resource in this limited way”signed The Privilege Holder

End User(PrivilegeHolder)

Assignsprivilege to

Delegates privilege to

“Can I use theResource”

Assigning and Delegating Privileges in Organisations

21 June 2006 Copyright 2006 University of Kent 7

Privilege Checking in Organisations

“Please purchase this product from company X” signed the End User

EndUser(PrivilegeHolder)

Privilege VerifierQ. “Is this user authorised to purchase these goods?”

Issues acommand(AssertsPrivilege)

21 June 2006 Copyright 2006 University of Kent 8

Access Control• Usually based on access control lists

– This list of users can do these things• Examples • Ed and Jake can read the exam results file on the

Kent University website• Jo and Zoe get 10% discount when electronically

shopping at Tescos

• PROBLEMS• You need to know the names of all the users• Very difficult to scale to Internet proportions where

there are millions of users

21 June 2006 Copyright 2006 University of Kent 9

Role Based Access Control

• Users are given roles (or attributes)• Holders of attributes are given access

permissions• Examples• Ed and Jake are Students at Kent University• Students at Kent University can read the exam

results file on the website• Jo and Zoe are Tesco Clubcard holders• Tesco Clubcard holders get 10% discount when

shopping electronically at Tescos

21 June 2006 Copyright 2006 University of Kent 10

Delegation of Authority with Role Based Access Controls

• Users who have attributes (or roles) can delegate these to other users

• Users can also delegate subordinate roles• E.g. professor is superior to academic staff is

superior to PG student is superior to UG student

• A professor can delegate the academic staff role, or the PG student role or the UG student role so as to delegate partial privileges

21 June 2006 Copyright 2006 University of Kent 11

Assigning Privileges Electronically - using X.509 Attribute Certificates

Bill

Alice

Bob

SOA

AA

IssuesAC to

IssuesAC to

EndEntity

AC

Points to issuer

Points toholder

SOA = Source of AuthorityAA = Attribute Authority

An Attribute Certificateis a digitally signed

electronic document thatsays that this holder has

been given these attributes by this issuer

21 June 2006 Copyright 2006 University of Kent 12

Main points of this system

• Every delegated attribute (or role) is digitally signed so that it cannot be tampered with or altered

• Each attribute certificate says who the delegator and delegatee are (issuer and holder)

• Very secure way of delegating authority

• BUT – each user needs a digital signing key and digital certificate

• How many of you have digital certificates and signing keys?

21 June 2006 Copyright 2006 University of Kent 13

Bill

Alice

Bob

SOA

AA

EndEntity

IssuesAC to

IssuesAC to

DelegationIssuing

Service (DIS)

IssuesAC to

AC

Points to issuer

Points toholder

Points to Issued OnBehalf Of

The Delegation Issuing Service

21 June 2006 Copyright 2006 University of Kent 14

Advantages of the Delegation Issuing Service

• Users don’t need to have signing keys since the DIS signs the Attribute Certificates on their behalf

• The DIS keeps a central record (audit trail) of who has delegated what to whom

• The DIS has a Delegation Policy to control who can delegate what to whom

• The process of privilege checking is very efficient since all ACs are issued by the DIS (and not by lots of different users)

21 June 2006 Copyright 2006 University of Kent 15

LDAPserver

Authenticatethe User

DIS

IssueACWeb serviceinterface

publishAC

PERMIS DecisionEngine

SignAC

Request

Authorisation

DelegationPolicy

Our DIS System

21 June 2006 Copyright 2006 University of Kent 16

The Delegation of Authority Demo• Public web page• Secure web page only available to users with

Researcher role• Role Hierarchy

• Anyone with Admin or Researcher role can delegate Researcher role to anyone else in Staff domain

21 June 2006 Copyright 2006 University of Kent 17

Delegation Demo (cont)

• Simon is already a researcher

• Simon would like to delegate to Sarah to access his resource

• Simon accesses the Delegation Issuing Service and assigns the Researcher role to Sarah

• Sarah can now access the resource

• Simon then revokes the researcher role

• Sarah no longer has access

21 June 2006 Copyright 2006 University of Kent 18

21 June 2006 Copyright 2006 University of Kent 19

21 June 2006 Copyright 2006 University of Kent 20

21 June 2006 Copyright 2006 University of Kent 21

21 June 2006 Copyright 2006 University of Kent 22

21 June 2006 Copyright 2006 University of Kent 23