[PPT] - Policy-based Access Control for Weakly Consistent Replication Based PowerPoint Presentation

SLIDE 1

Policy-based Access Control for Weakly Consistent Replication

Based on paper written by Ted Webber, Thomas L. Rodeheffer and Douglas B. Terry

SLIDE 2

Outline

What’s the problem?
Definitions
System design

– Operation on data – Updating policies – Mantaining weak consistency

Summary
Questions

SLIDE 3

What’s the problem?

Suppose we have

small network

We want to share

resources between devices

All devices should

have different access rights

SLIDE 4

What’s the problem?

We want to grant limited access to resource

for every replica according to the policy

Replicas are not uniformly trusted
Data can change
Data can be divided into categories
Policy can change
State must be (eventually) consistent

SLIDE 5

That’s not so easy!

Each replica has its policy P and dataset U

P, U P, U A B P’, U P, U’ A B P’, U P, U’ A B P’, U P’, U’ A B T0 T1 T2 T3 P’ U’ U’ P’

SLIDE 6

Definitions

Collection is a dataset to replicate

– e.g. FS subtree, SQL database, personal contacts...

Collections consist of items, which are atomic
Collections appear in whole or in part on

replicas

SLIDE 7

Assumptions

The network is consistent

– All updates will reach eventually all authorized replicas

All updates take place in either of two ways

– Through direct invocation – By helper application, like FS watcher

Replicas synchronize periodically
Only weak consistency is guaranteed

SLIDE 8

Observations

Updates can arrive out of order
There can occur replication conflict –

concurrent update of the same item

Local view of policy can vary between replicas

SLIDE 9

System design

Items access and update by particular replicas
Policy access and update
Providing eventual consistency

SLIDE 10

Operations on items

Let’s specify three primitive operations:

Write

– When a replica receives an item during synchronization

Read

– When a replica is considering wether to send an item during synchronization

Sync

– When a replica receives protocol-specific metadata required for performance or correctness

SLIDE 11

Operation on items

And two additional, administrative rights:

Control

– Means that the replica can grant rights to read and write to other replicas

Own

– Means that the replica can grant any rights to other replicas, including

wn and control

SLIDE 12

Example

SLIDE 13

Example

Replica Read Write Sync Control Own HomePC All All All All All Laptop All All All Contacts Contacts MediaPlayer Photos

Cloud

All

All
Work

Contacts Contacts

Mobile

Contacts Contacts

Contacts
SpouseMobile

Contacts

SLIDE 14

Replicas

Every replica has its own set of rights to

different types of items

Every replica has unique public key
Update is signed with author’s public key to

determine the authorship

We have three special replicas

– Local Authority (LA) – Annonymous – Collection Manager (CM)

SLIDE 15

Labels

Due to performance issues, the policy is not

defined for every single item

Items are divided into classes represented by

labels

Labels are immutuable
Can be structured in hierarchcal namespace
In the example we have two labels: contacts and

photos

SLIDE 16

Items

Items are bound to certain label
It is impossible to change item’s label
Item’s identifier is of the form uniqueId$hash,

where hash is cryptographic hash of the corresponding label

By signing an item, a replica declares that it has write

permissions on the assosiated label. What if replica is bogus?

SLIDE 17

Policies

Policy is set of claims
Claims are used to prove target assertions
In the described protocol authors use SecPAL

evaluator which operates on XML objects

SLIDE 18

Claims

Claim is a statement made by replica about a fact

„A says B can write contacts” OR „A says B can write contacts if B can write photos”

Facts come in four forms:

– „A says B can ...” – „A says B can say ...” – „A says B revokes ...” – „A says B can revoke ...”

SLIDE 19

Special Replicas

Let’s remind that we introduced three special replicas:

Local Authority (LA)

– Any direct claim made by LA is believed – All such claims are hard-coded as policy axioms

Anonymous

– Means „everybody” – All claims refering to Anonymous refers to anybody

Collection Manager (CM)

– Has all rights to all resources – Holds only replicated policy

SLIDE 20

Policy axioms

Policy axioms are hard-coded as LA claims:

„LA says P can say Q can {read, write} L if P can control L” „LA says P can {read, write, sync, control} L if P can own L” „LA says P can say Q can {own, read, write, sync, control} L if P can own L” „LA says CM can own all”

SLIDE 21

Target assertion

Target assertion is a final claim that we want

to prove

Supose we want to check if Mobile can write contacts

The target assertion takes form of: „LA says Mobile can write contacts” Proof proceeds with using claims made by authorized replicas

SLIDE 22

Delegating specific rights

In order to make a target assertion provable

we have to add more claims

Continuing the example from slides 12-13 we create

new claim „CM says HomePC can own all”

Policy claims are signed by their issuers

SLIDE 23

Delegating specific rights

HomePC creates replicas for Cloud and MediaPlayer

and creates following claims:

„HomePC says Laptop can {read, write, sync} all” „HomePC says Laptop can own contacts” „HomePC says Cloud can {read, sync} all” „HomePC says MediaPlayer can read photos”

Afterwards Laptop creates replicas for Work and

Mobile, and so on...

SLIDE 24

Policy representation

Policy claims are encoded as XML files and

stored in collection items called policy items

These are regular items, so we bind them to

label policy and we add two more claims

„CM says Anonymous can read policy” „HomePC says Laptop can write policy.homepc.laptop”

SLIDE 25

Example of proof

SLIDE 26

Revocation

Revocation claims are more less the same as

normal policy update

„Laptop says Laptop revokes write contacts from Mobile”

May result in invalidation of previously valid

items!

It is impossible to revoke revocation or revocation

right

SLIDE 27

Revocation conflict

There are two ways to deal with revocation

conflict

– Invalidate all affected items – Honor historical claims and disallow only new dependencies on revoked claims

In the solution proposed by authors the

second option is implemented (with one exception)

SLIDE 28

Summary of design

Policy is encoded in a logical language
Authority flows from a single root (CM)
Access control checks are performed within

the operations that implement data replication

Encoded policy is replicated as data

SLIDE 29

Mantaining consistency

There are separate items for any claims

uttered by a given replica

– Allows simultaneous policy updates

Read access controls do not apply to policy

items

– Replica cannot prevent policy from propagating

SLIDE 30

Difficult example

Let’s remind example from slide 5, how the system sould behave?

P, U P, U A B P’, U P, U’ A B P’, U P, U’ A B P’, U P’, U’ A B T0 T1 T2 T3 P’ U’ U’ P’

SLIDE 31

Difficult example - answer

If U’ is not authorized at authoring replica,

then the update will not be admitted

If U’ is not authorized at receiving replica,

then transmission of U’ is retried periodically until P’ arrives a the destination

If U’ was inappropriately authorized before

receiving P’, the replica must reevaluate all previously received items

SLIDE 32

Design - summary

Single root of authority
Identity determined with public key
Updating after checking the policy
Policy as normal items
Limitations on revoking claims
Binding of labels and data

SLIDE 33

Questions

SLIDE 34

References

T. Wobber, T. L. Rodeheffer, D. B. Terry. Policy-based Access