Cooperative Secondary Authorization Recycling Qiang Wei, Matei - - PowerPoint PPT Presentation

cooperative secondary authorization recycling
SMART_READER_LITE
LIVE PREVIEW

Cooperative Secondary Authorization Recycling Qiang Wei, Matei - - PowerPoint PPT Presentation

Cooperative Secondary Authorization Recycling Qiang Wei, Matei Ripeanu, Konstantin Beznosov Laboratory for Education and Research in Secure Systems Engineering (lersse.ece.ubc.ca) University of British Columbia Typical Authorization


slide-1
SLIDE 1

Cooperative Secondary Authorization Recycling

Qiang Wei, Matei Ripeanu, Konstantin Beznosov

Laboratory for Education and Research in Secure Systems Engineering (lersse.ece.ubc.ca)

University of British Columbia

slide-2
SLIDE 2

Laboratory for Education and Research in Secure Systems Engineering (lersse.ece.ubc.ca) 2

authorization server application server

Typical Authorization Architecture

protected application

  • bjects

client

application request authorization request authorization response application response

subject

Also known as request-response paradigm e.g. IBM Access Manager, EJB, XACML

(subject,

  • bject, read)

(request, allow)

Policy Enforcement Point (PEP) Policy Decision Point (PDP)

slide-3
SLIDE 3

Laboratory for Education and Research in Secure Systems Engineering (lersse.ece.ubc.ca) 3

Motivation Problems

PEP PEP PEP PDP

reduced availability reduced scalability

slide-4
SLIDE 4

Laboratory for Education and Research in Secure Systems Engineering (lersse.ece.ubc.ca) 4

Secondary and Approximate Authorization Model (SAAM)

PEP PEP PEP PDP SDP SDP SDP

  • 1. reuse cached responses
  • 2. infer approximate responses

Secondary Decision Point (SDP)

Secondary Authorization Recycling

slide-5
SLIDE 5

Laboratory for Education and Research in Secure Systems Engineering (lersse.ece.ubc.ca) 5

Cooperative Secondary Authorization Recycling

SDP SDP SDP Discovery Service

each SDP serves only its own PEP! all SDPs cooperate to serve all PEPs

slide-6
SLIDE 6

Laboratory for Education and Research in Secure Systems Engineering (lersse.ece.ubc.ca) 6

A Simplified Example

SDP SDP SDP Discovery Service Alice’s subject id= Alice role= preferred customer Bob’s subject id= Bob role= customer

allow (an approximate response) allow

new request previous request

slide-7
SLIDE 7

Laboratory for Education and Research in Secure Systems Engineering (lersse.ece.ubc.ca) 7

Contributions

Proposed

  • the concept of

cooperative secondary authorization recycling

  • system architecture &

detailed design

Evaluated

  • availability
  • performance

SDP SDP SDP Discovery Service

slide-8
SLIDE 8

Laboratory for Education and Research in Secure Systems Engineering (lersse.ece.ubc.ca) 8

Key Design Features

slide-9
SLIDE 9

Laboratory for Education and Research in Secure Systems Engineering (lersse.ece.ubc.ca) 9

Consistency: Support Critical Policy Changes

Policy Change Manager SDP SDP SDP

Policy Changes

  • 1. find affected SDPs
  • 2. find affected caches

propagate policy changes to affected SDPs immediately

Security Administrator Policy Store

Detect Critical (t)

slide-10
SLIDE 10

Laboratory for Education and Research in Secure Systems Engineering (lersse.ece.ubc.ca) 10

Consistency: Support Time-sensitive Policy Changes

SDP SDP SDP

A TTL approach: delete expired responses periodically

Policy Change Manager

Detect Policy Changes

Security Administrator Policy Store

Time-sensitive

slide-11
SLIDE 11

Laboratory for Education and Research in Secure Systems Engineering (lersse.ece.ubc.ca) 11

SDP

Support Untrusted Remote SDPs

PEP SDP SDP

Verify responses made by remote SDPs

  • 1. verify the authenticity

and integrity

  • 2. verify the correctness of

inference

Malicious SDP

PDP

Trusted by all SDPs

Trusts Trusts

Does NOT Trust

slide-12
SLIDE 12

Laboratory for Education and Research in Secure Systems Engineering (lersse.ece.ubc.ca) 12

Configurability

Three decision points

  • local SDP & remote SDPs & the PDP

To reduce network traffic & PDP’s load

  • sequential authorization

To reduce the response time

  • concurrent authorization

1

SDP

2 3

PEP remote SDPs PDP SDP

1 1 1

PEP remote SDPs PDP

slide-13
SLIDE 13

Laboratory for Education and Research in Secure Systems Engineering (lersse.ece.ubc.ca) 13

Evaluation Results

via simulation & prototype implementation

slide-14
SLIDE 14

Laboratory for Education and Research in Secure Systems Engineering (lersse.ece.ubc.ca) 14

Simulation-based Evaluation

Metrics

  • cache hit rate

Methodology Affecting factors

  • cache warmness =
  • number of cooperating SDPs
  • verlap rate O12 =

|cached requests without replacement| |total possible requests|

|R12| |R1|

R – resource space SDP1 SDP2

simulation engine testing set training set

slide-15
SLIDE 15

Laboratory for Education and Research in Secure Systems Engineering (lersse.ece.ubc.ca) 15

Hit Rate Dependence on Cache Warmness

5 SDPs

High hit rate is achieved even when cache warmness is low

slide-16
SLIDE 16

Laboratory for Education and Research in Secure Systems Engineering (lersse.ece.ubc.ca) 16

Hit Rate Dependence on Number of SDPs

10% cache warmness at each SDP

Increasing the number of cooperating SDPs leads to higher hit rates Additional SDPs provide diminishing returns

slide-17
SLIDE 17

Laboratory for Education and Research in Secure Systems Engineering (lersse.ece.ubc.ca) 17

Prototype-based Evaluation

Metrics

  • average client-perceived response time
  • hit rate

Methodology Affecting factors

  • number of requests
  • response verification
  • frequency of policy change

JAVA RMI

PDP test driver

SDP

PEP

SDP

PEP

discovery service

slide-18
SLIDE 18

Laboratory for Education and Research in Secure Systems Engineering (lersse.ece.ubc.ca) 18

Response Time Dependence on Number of Requests

4 SDPs (CSAR), 100% overlap, 40ms RTT between PDP and each SDP

  • 1. Cooperation can contribute to reduced response time
  • 2. The impact of response verification is small
slide-19
SLIDE 19

Laboratory for Education and Research in Secure Systems Engineering (lersse.ece.ubc.ca) 19

How will regular policy changes affect hit rate?

1 SDP

  • 1. Hit-rate drop caused by each

policy change is small

  • 2. Cumulative effect of policy

changes is significant

  • 1. The hit rates stabilize after

the knee

  • 2. More frequent policy

changes lead to lower hit rates

slide-20
SLIDE 20

Laboratory for Education and Research in Secure Systems Engineering (lersse.ece.ubc.ca) 20

How does cooperation help?

100% overlap, policy changes at 100 requests/change

Cooperation improves hit rates when policy changes

slide-21
SLIDE 21

Laboratory for Education and Research in Secure Systems Engineering (lersse.ece.ubc.ca) 21

Related Work

Authorization recycling

(Bauer et al. 2005, Borders et al. 2005)

Collaborative web caching

(Lyer et al. 2002, Wolman et al. 1999, Chankhunthod et al. 1996)

Collaborative security

(Locasto et al. 2006, Costa et al. 2005)

Secondary and Approximate Authorization Model (SAAM)

(Crampton et al. 2006, Beznosov 2005)

CSAR

slide-22
SLIDE 22

Laboratory for Education and Research in Secure Systems Engineering (lersse.ece.ubc.ca) 22

Summary

PE P PE P PE P PD P

reduced availability reduced scalability

SDP SDP SDP Discovery Service

slide-23
SLIDE 23

Laboratory for Education and Research in Secure Systems Engineering (lersse.ece.ubc.ca) 23

lersse.ece.ubc.ca