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

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 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? DOCsec ‘99 2 Konstantin Beznosov C:\data\presentations\rad\to-docsec-99\presentation.fm 15-Jul-1999

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) DOCsec ‘99 3 Konstantin Beznosov C:\data\presentations\rad\to-docsec-99\presentation.fm 15-Jul-1999

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 DOCsec ‘99 4 Konstantin Beznosov C:\data\presentations\rad\to-docsec-99\presentation.fm 15-Jul-1999

Why Do You Need Resource Access Decision Facility? DOCsec ‘99 5 Konstantin Beznosov C:\data\presentations\rad\to-docsec-99\presentation.fm 15-Jul-1999

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 DOCsec ‘99 6 Konstantin Beznosov C:\data\presentations\rad\to-docsec-99\presentation.fm 15-Jul-1999

Why RAD? • Access control granularity • Additional factors in authorization decisions • Decoupling authorization logic from application logic DOCsec ‘99 7 Konstantin Beznosov C:\data\presentations\rad\to-docsec-99\presentation.fm 15-Jul-1999

Why RAD: Granularity DOCsec ‘99 8 Konstantin Beznosov C:\data\presentations\rad\to-docsec-99\presentation.fm 15-Jul-1999

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. DOCsec ‘99 9 Konstantin Beznosov C:\data\presentations\rad\to-docsec-99\presentation.fm 15-Jul-1999

Main Aspects of RAD Specification Design DOCsec ‘99 10 Konstantin Beznosov C:\data\presentations\rad\to-docsec-99\presentation.fm 15-Jul-1999

Users, Clients, Services, RAD C lient s e c i v r U ser e S data and services n access requests o RAD i authorization t requests a c i C lient l p p A U ser DOCsec ‘99 11 Konstantin Beznosov C:\data\presentations\rad\to-docsec-99\presentation.fm 15-Jul-1999

Interaction Between RAD Parts an Application System 6: 1: access_allow ed(R esourceN ame, Operation, AttributeList) an Access D ecision 4: co mbine_decisions(R esourceN ame, O peration, Attribu teList, PolicyEvaluatorList) O bject : AccessD ecision a C ombinator : D ecisionC ombinator 2: get_policy_decision_ev aluators(R esourceN ame) a Locator : Policy Ev aluatorLocator 5: * ev aluate(R esourceN am e, O peration, AttributeList) 3: get_dynam ic_attributes(AttributeList, ResourceN ame, Operation) an Attribute Serv ice : D ynamicAttributeServ ice an E va luator : PolicyEv aluator DOCsec ‘99 12 Konstantin Beznosov C:\data\presentations\rad\to-docsec-99\presentation.fm 15-Jul-1999

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. DOCsec ‘99 13 Konstantin Beznosov C:\data\presentations\rad\to-docsec-99\presentation.fm 15-Jul-1999

RAD Main Parts: Administrative <<IDL Interface>> <<IDL Interface>> PolicyEvaluatorLocatorBasicAdmin Access DecisionAdmin set_default_evaluators() get_policy_evaluator_locator() get_default_combinator() set_policy_evaluator_locator() set_default_combinator() get_dynamic_attribute_service() get_default_evaluators() set_dynamic_attribute_service() <<ID L Interface>> Po licyE valuatorL ocatorNa meAdmi n <<ID L Interface>> set_evaluators () P oli cyEvaluato rAd mi n add _evaluators() s et_policies () del ete _evaluators () add_policies () get_evaluators () lis t_policies () set_com binator() s et_default_ policy() de lete_com binator() delete_policies () get_com binator() DOCsec ‘99 14 Konstantin Beznosov C:\data\presentations\rad\to-docsec-99\presentation.fm 15-Jul-1999

Resource and Operation Names • Resource names are for expressing arbitrary resources in the form of a data structures convenient for manipulations. ResourceNameComponent ResourceNamingAuthority ResourceNameComponentList name_string : string value_string[0..1] : string 0..1 0..1 1..* 1..* 1..1 1..1 1..1 1..1 +resource_name_authority +resource_name_component_list 0..1 0..1 0..1 0..1 ResourceName • All access operations are named DOCsec ‘99 15 Konstantin Beznosov C:\data\presentations\rad\to-docsec-99\presentation.fm 15-Jul-1999

Main Design Decisions DOCsec ‘99 16 Konstantin Beznosov C:\data\presentations\rad\to-docsec-99\presentation.fm 15-Jul-1999

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 DOCsec ‘99 17 Konstantin Beznosov C:\data\presentations\rad\to-docsec-99\presentation.fm 15-Jul-1999

Grouping Resources and Resource Names • Resource are grouped using resource names • Resource names are grouped using resource name patterns << ID L In te rfa ce >> 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 () DOCsec ‘99 18 Konstantin Beznosov C:\data\presentations\rad\to-docsec-99\presentation.fm 15-Jul-1999

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 object with all bells and whistles. DOCsec ‘99 19 Konstantin Beznosov C:\data\presentations\rad\to-docsec-99\presentation.fm 15-Jul-1999

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. DOCsec ‘99 20 Konstantin Beznosov C:\data\presentations\rad\to-docsec-99\presentation.fm 15-Jul-1999

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 DOCsec ‘99 21 Konstantin Beznosov C:\data\presentations\rad\to-docsec-99\presentation.fm 15-Jul-1999