A typed Access Control Model for CORBA

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