Resource Access Decision Facility: Overview Konstantin Beznosov - - PowerPoint PPT Presentation

▶
resource access decision facility overview
SMART_READER_LITE
LIVE PREVIEW

Resource Access Decision Facility: Overview Konstantin Beznosov - - PowerPoint PPT Presentation

Mar 06, 2023 103 likes •330 views

Resource Access Decision Facility: Overview Konstantin Beznosov Baptist Health Systems of South Florida beznosov@baptisthealth.net DOCsec 99 1 Konstantin Beznosov C:\data\presentations\rad\to-docsec-99\presentation.fm 15-Jul-1999 Do You

slide-1
SLIDE 1

DOCsec ‘99 1

15-Jul-1999 C:\data\presentations\rad\to-docsec-99\presentation.fm Konstantin Beznosov

Resource Access Decision Facility: Overview

Konstantin Beznosov Baptist Health Systems of South Florida beznosov@baptisthealth.net

slide-2
SLIDE 2

DOCsec ‘99 2

15-Jul-1999 C:\data\presentations\rad\to-docsec-99\presentation.fm Konstantin Beznosov

Do You Have Any of the Following:

  • Systems from different vendors are deployed
  • Either granularity of access control needs to be fine
  • Access control policies are complex and relatively dynamic
  • Free lunch?
slide-3
SLIDE 3

DOCsec ‘99 3

15-Jul-1999 C:\data\presentations\rad\to-docsec-99\presentation.fm Konstantin Beznosov

Presentation Overview

  • Why you need Resource Access Decision Facility
  • Main aspects of RAD specification design
  • Main design decisions made by RAD submission team
  • Questions (if time permits)
slide-4
SLIDE 4

DOCsec ‘99 4

15-Jul-1999 C:\data\presentations\rad\to-docsec-99\presentation.fm Konstantin Beznosov

RAD Trivia

  • Response to Healthcare Resource Access Control (HRAC) RFP

corbamed/98-02-23

  • Final response corbamed/99-05-04
  • FTF August 1999
  • Who did it:
  • 2AB, IBM, NIST, BHS
  • With help from: CareFlow|Net, Concept Five, DASCOM, Inc., Inprise, Los

Alamos National Laboratory, NSA, Philips Medical Systems, TIS Labs

slide-5
SLIDE 5

DOCsec ‘99 5

15-Jul-1999 C:\data\presentations\rad\to-docsec-99\presentation.fm Konstantin Beznosov

Why Do You Need Resource Access Decision Facility?

slide-6
SLIDE 6

DOCsec ‘99 6

15-Jul-1999 C:\data\presentations\rad\to-docsec-99\presentation.fm Konstantin Beznosov

CORBASEC

  • Versatile
  • Accommodates most computing environments
  • Optimized for the most common case
  • Provides interfaces to applications if their security needs differ

from the common case

  • Do not pay if don’t use
slide-7
SLIDE 7

DOCsec ‘99 7

15-Jul-1999 C:\data\presentations\rad\to-docsec-99\presentation.fm Konstantin Beznosov

Why RAD?

  • Access control granularity
  • Additional factors in authorization decisions
  • Decoupling authorization logic from application logic
slide-8
SLIDE 8

DOCsec ‘99 8

15-Jul-1999 C:\data\presentations\rad\to-docsec-99\presentation.fm Konstantin Beznosov

Why RAD: Granularity

slide-9
SLIDE 9

DOCsec ‘99 9

15-Jul-1999 C:\data\presentations\rad\to-docsec-99\presentation.fm Konstantin Beznosov

Why RAD: Additional Factors

  • Some Need Authorization Decisions Based on
  • Standard CORBASEC Access Control Model
  • Name of interface and operation
  • Principal id
  • Principal role
  • Principal affiliation
  • ...
  • Customized implementation of AccessDecision and

PrincipalAuthenticator

  • Time of service request
  • Location of service requester
  • Cannot be supported by CORBASEC Access Control Model
  • Relationship between the requesting principal and the “owner” of the data to be accessed
  • Values of input arguments on an operation.
  • Values of results returned from invocation of an operation.
slide-10
SLIDE 10

DOCsec ‘99 10

15-Jul-1999 C:\data\presentations\rad\to-docsec-99\presentation.fm Konstantin Beznosov

Main Aspects of RAD Specification Design

slide-11
SLIDE 11

DOCsec ‘99 11

15-Jul-1999 C:\data\presentations\rad\to-docsec-99\presentation.fm Konstantin Beznosov

Users, Clients, Services, RAD

A p p l i c a t i

  • n

S e r v i c e s

C lient

RAD

U ser

C lient

U ser

authorization requests data and services access requests

slide-12
SLIDE 12

DOCsec ‘99 12

15-Jul-1999 C:\data\presentations\rad\to-docsec-99\presentation.fm Konstantin Beznosov

Interaction Between RAD Parts

an Access D ecision O bject : AccessD ecision an Application System a Locator : Policy Ev aluatorLocator an E va luator : PolicyEv aluator an Attribute Serv ice : D ynamicAttributeServ ice a C

  • mbinator :

D ecisionC

  • mbinator

2: get_policy_decision_ev aluators(R esourceN ame) 3: get_dynam ic_attributes(AttributeList, ResourceN ame, Operation) 4: co mbine_decisions(R esourceN ame, O peration, Attribu teList, PolicyEvaluatorList) 1: access_allow ed(R esourceN ame, Operation, AttributeList) 6: 5: * ev aluate(R esourceN am e, O peration, AttributeList)

slide-13
SLIDE 13

DOCsec ‘99 13

15-Jul-1999 C:\data\presentations\rad\to-docsec-99\presentation.fm Konstantin Beznosov

RAD Main Parts: Runtime

  • AccessDecision
  • one per facility
  • the facade to the facility and a mediator
  • DynamicAttributeService
  • one per facility, can be replace
  • updates the list of security attributes with dynamic ones
  • PolicyEvaluatorLocator
  • one per facility, can be replaced
  • provides a list of policy evaluators and a combinator for a given authorization request
  • PolicyEvaluators
  • one or more per request, dynamically discovered
  • evaluate policies that they implement and return evaluation result
  • DecisionCombinator
  • one per request, dynamically discovered
  • calls appropriate evaluators and combines decisions from them in one grant/deny.
slide-14
SLIDE 14

DOCsec ‘99 14

15-Jul-1999 C:\data\presentations\rad\to-docsec-99\presentation.fm Konstantin Beznosov

RAD Main Parts: Administrative

Access DecisionAdmin get_policy_evaluator_locator() set_policy_evaluator_locator() get_dynamic_attribute_service() set_dynamic_attribute_service() <<IDL Interface>> PolicyEvaluatorLocatorBasicAdmin set_default_evaluators() get_default_combinator() set_default_combinator() get_default_evaluators() <<IDL Interface>> Po licyE valuatorL ocatorNa meAdmi n set_evaluators () add _evaluators() del ete _evaluators () get_evaluators () set_com binator() de lete_com binator() get_com binator() <<ID L Interface>> P oli cyEvaluato rAd mi n s et_policies () add_policies () lis t_policies () s et_default_ policy() delete_policies () <<ID L Interface>>

slide-15
SLIDE 15

DOCsec ‘99 15

15-Jul-1999 C:\data\presentations\rad\to-docsec-99\presentation.fm Konstantin Beznosov

Resource and Operation Names

  • Resource names are for expressing arbitrary resources in the

form of a data structures convenient for manipulations.

  • All access operations are named

ResourceName 0..1 1..1 0..1 1..1 0..1 0..1 1..1 +resource_name_authority ResourceNamingAuthority ResourceNameComponentList +resource_name_component_list 1..1 0..1 0..1 1..* 1..* ResourceNameComponent name_string : string value_string[0..1] : string

slide-16
SLIDE 16

DOCsec ‘99 16

15-Jul-1999 C:\data\presentations\rad\to-docsec-99\presentation.fm Konstantin Beznosov

Main Design Decisions

slide-17
SLIDE 17

DOCsec ‘99 17

15-Jul-1999 C:\data\presentations\rad\to-docsec-99\presentation.fm Konstantin Beznosov

Policies and Dynamic Attributes

  • Policies
  • No interfaces for expressing authorization policies
  • Policies and policy engines are encapsulated in CORBA objects and can

be supplied by different vendors.

  • Dynamic Attributes
  • Request-specific factors in the form of dynamic attributes
  • CORBASEC + RAD + application service == reference monitor
slide-18
SLIDE 18

DOCsec ‘99 18

15-Jul-1999 C:\data\presentations\rad\to-docsec-99\presentation.fm Konstantin Beznosov

Grouping Resources and Resource Names

  • Resource are grouped using resource names
  • Resource names are grouped using resource name patterns

P oli cyE va lu a to r L oca to rP a tte rn A d m in s e t_ e va lu a to rs _ b y_ p a tte rn () a d d _ e va lu a to rs _ b y_ p a tte rn () d e le te _ e va lu a to rs _ b y_ p a tte rn () g e t_ e va lu a to rs _ b y_ p a tte rn () s e t_ co m b in a to r_ b y_ p a tte rn () d e le te _ co m b in a to r_ b y_ p a tte rn () g e t_ co m b in a to r_ b y_ p a tte rn () re g is te r_ re s o u rce _ n a m e _ p a tte rn () u n re g is te r_ re s o u rce _ n a m e _ p a tte rn () << ID L In te rfa ce >>

slide-19
SLIDE 19

DOCsec ‘99 19

15-Jul-1999 C:\data\presentations\rad\to-docsec-99\presentation.fm Konstantin Beznosov

Accommodates Different Flexibility and Performance Requirements

  • Neither part of RAD have to be co-located with its clients
  • Only security attributes are passed, Credentials object is not passed
  • Everything could be packed in the same process space as the

application service, or

  • Every single part of RAD could be a separate full-blown CORBA
  • bject with all bells and whistles.
slide-20
SLIDE 20

DOCsec ‘99 20

15-Jul-1999 C:\data\presentations\rad\to-docsec-99\presentation.fm Konstantin Beznosov

Design by Contract

  • Contract between the caller and the callee
  • Preconditions
  • Postconditions
  • Exceptions
  • Exception is thrown to the RAD client if something goes wrong
  • Different treatment of run-time and administrative interfaces
  • Expects input errors and inconsistencies of operation invocations on

administrative interfaces.

  • Assumes that ADO client and all RAD parts are debugged, i.e. has strict

preconditions.

slide-21
SLIDE 21

DOCsec ‘99 21

15-Jul-1999 C:\data\presentations\rad\to-docsec-99\presentation.fm Konstantin Beznosov

Conclusions

  • RAD is useful when:
  • Systems from different vendors are deployed
  • Either granularity of access control needs to be finer, or
  • Access control policies are complex and relatively dynamic
  • Authorization decisions
  • Made in regards to fine-grain resources
  • Based on factors specific to the user session, workflow, request
  • Resource names
  • Abstract real resources
  • Could be grouped using patterns