1 / 18

A typed Access Control Model for CORBA

A typed Access Control Model for CORBA. Gerald Brose Institut für Informatik Freie Universität Berlin, Germany ESORICS 2000, October 4-6, Toulouse, France. Roadmap. 1. Why another Access Control Model? 2. View-based access control 3. Case Study 4. Raccoon Architecture.

viveka
Download Presentation

A typed Access Control Model for CORBA

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. A typed Access Control Model for CORBA Gerald Brose Institut für Informatik Freie Universität Berlin, Germany ESORICS 2000, October 4-6, Toulouse, France

  2. Roadmap 1. Why another Access Control Model? 2. View-based access control 3. Case Study 4. Raccoon Architecture ESORICS 2000, October 5

  3. 1. YAM - Yet Another Model? • Existing models do not fit CORBA environments: • heterogeneous policy management • homogeneous object model (IDL) • most models use generic rights • take no advantage of typed object model • mapping to operations is left „to the implementation“ or the designer • practical access control for CORBA = fine-grained + scalable + manageable ESORICS 2000, October 5

  4. Who deals with Access Policies? • (Global IT Security Managers) • Developers • define application scenarios, design interfaces • need to define some static policy properties: principle of least privilege • Deployers • install and adapt policies • assign objects to policy domains, users to roles • Managers • manage users, roles, objects, domains • evolve policies ESORICS 2000, October 5

  5. Example: CORBA Access Model • Rights in families: corba:gsmu (=rwmx) • Specification in two tables:“required rights” vs. “effective rights” • Example policy for name service access: • resolve a name • list bindings • bind a name • bind a subcontext • unbind names, destroy contexts ESORICS 2000, October 5

  6. Effective vs. Required Rights • Granted by Policy • per domain • Group operations by „sensitivity“ • specified by developers • per-type! • system-wide! ESORICS 2000, October 5

  7. Restrictions • Granularity vs. Scalability • restricted set of rights  collisions • all objects of a type treated alike • Hard to specify and manage: • not expressive • no dynamic changes • no denials • limited semantics of rights • error-prone • untyped, low-level (“Object rwx”) • policy semantics are easily lost ESORICS 2000, October 5

  8. 2. View-based Access Control • Manageability  language support: VPL • Abstraction • Documentation, Communication, Reuse • fixed object model: IDL • static consistency checks • Fine-grained • rights for individual operations on objects • Scalability  Grouping: • Rights: Views and Roles • Objects: Domains ESORICS 2000, October 5

  9. view Resolving controls NamingContext { allow resolve; } view Binding : Resolving { allow bind; bind_new_context; } Access Matrix Model Object n:NamingCtx o2:Paper o3:Review o4:T Roleresolve Employeebind read bind_new_ctx. Secretary resolve append correctlist read read resolve read read TechAuthor list, bind, write ResolvingBinding ESORICS 2000, October 5

  10. Views • are “higher-level authorizations” • group rights • contain type-specific permissions and denials for operations • allow consistency checks IDL: VPL: interface Document { view Reading controls Document{ void read(out string s);allow read; void write(in string s); } void append(in string s);view Writing: Reader void correct(in string s); restricted_to Author { }; allow write; append; } ESORICS 2000, October 5

  11. Roles in VPL • emphasize use-case view on policies • support division of labor • Standard RBAC [Sandhu et al. 96]: RoleName  2Users X 2Rights • VPL: • static: actors with viewsRoleName  2Views • Assigning users to roles is done at deployment time ESORICS 2000, October 5

  12. 3. Case Study Support reviewing of conference papers (à la CyberChair): 1. Authors submit papers 2. Reviewers submit reviews 3. Reviewers may read other reviews and change their own review. Application-level policy with dynamic changes in the protection state: • Deadline reached: no more papers • Review submitted: read other reviews ESORICS 2000, October 5

  13. interface Conference {// change working phase void callForPapers(); void deadlineReached();void makeDecision();void submitPaper(in string paper);void listPapers(out string list);Paper getPaper(in long paper); }; interface Paper {void read(out string text);Review submitReview(in string rev,in long reviewer);void listReviews(out string list);Review getReview(in long reviewer); }; interface Review {void read(out string text);void update(in string text); }; Interfaces ESORICS 2000, October 5

  14. policy ConferenceReviewing { view AccessingPapers controls Conference {allow listPapers; getPaper; } view Reviewing controls Paper {allow read; listReviews; } view ConferenceSteering: AccessingPapersrestricted_to Chair {allow callForPapers; deadlineReached; makeDecision; } ... }; Views ESORICS 2000, October 5

  15. IDL: interface Paper { Review submitReview(in string text);}; VPL: schema Paper { submitReviewgrants result.update to caller;grants this.getReview to caller;revokes this.submitReview from caller; } Dynamic Changes: Schemas • regular changes triggered by operations ESORICS 2000, October 5

  16. Roles policy ConferenceReviewing{ view AccessingPapers {...} view Reviewing {...} view ConferenceSteering {...} view Submitting {...} schema Paper{...} roles Chair holds ConferenceSteering; Member holds Reviewing; Author holds Submitting; role assertion Author excludes Chair;card Chair = 1; } ESORICS 2000, October 5

  17. Role Mgmt. Domain Mgmt. Policy Mgmt. Policy Server Role Server Domain Server Roles 4. Raccoon Architecture Domain Policy Object Principal Client Server access_object() allow/deny access? ESORICS 2000, October 5 Kontext

  18. Project stage • currently: XML-based VPL compiler • Domain Server: done. • CORBA: IIOP/SSL and Portable Interceptors integrated in JacORB • To do: • Role and Policy Servers • Visualizations and GUI management • Demonstrate feasibility and manageability ESORICS 2000, October 5

More Related