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. Gerald Brose, Freie Universität Berlin 2ESORICS 2000, October 5 Roadmap 1. Why another Access Control Model? 2. View-based access control 3. Case Study 4. Raccoon Architecture

3. Gerald Brose, Freie Universität Berlin 3ESORICS 2000, October 5 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

4. Gerald Brose, Freie Universität Berlin 4ESORICS 2000, October 5 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

5. Gerald Brose, Freie Universität Berlin 5ESORICS 2000, October 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

6. Gerald Brose, Freie Universität Berlin 6ESORICS 2000, October 5 Effective vs. Required Rights  Group operations by „sensitivity“  specified by developers per-type! system-wide!  Granted by Policy  per domain

7. Gerald Brose, Freie Universität Berlin 7ESORICS 2000, October 5 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

8. Gerald Brose, Freie Universität Berlin 8ESORICS 2000, October 5 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

9. Gerald Brose, Freie Universität Berlin 9ESORICS 2000, October 5 Object n:NamingCtx o2:Paper o3:Review o4:T Role resolve Employee bind read bind_new_ctx. Secretary resolve append correct list read read resolve read read TechAuthor list, bind, write Access Matrix Model Resolving Binding view Resolving controls NamingContext { allow resolve; } view Binding : Resolving { allow bind; bind_new_context; }

10. Gerald Brose, Freie Universität Berlin 10ESORICS 2000, October 5 Views 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; }  are “higher-level authorizations”  group rights  contain type-specific permissions and denials for operations  allow consistency checks

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

12. Gerald Brose, Freie Universität Berlin 12ESORICS 2000, October 5 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

13. Gerald Brose, Freie Universität Berlin 13ESORICS 2000, October 5 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

14. Gerald Brose, Freie Universität Berlin 14ESORICS 2000, October 5 policy ConferenceReviewing { view AccessingPapers controls Conference { allow listPapers; getPaper; } view Reviewing controls Paper { allowread; listReviews; } view ConferenceSteering: AccessingPapers restricted_to Chair { allowcallForPapers; deadlineReached; makeDecision; }... }; Views

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

16. Gerald Brose, Freie Universität Berlin 16ESORICS 2000, October 5 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; } Roles

17. Gerald Brose, Freie Universität Berlin 17ESORICS 2000, October 5 4. Raccoon Architecture Client Server access_object() Object allow/deny access? DomainPolicy Kontext Principal Role Mgmt.Domain Mgmt. Policy Mgmt. Role Server Policy Server Domain Server Roles

18. Gerald Brose, Freie Universität Berlin 18ESORICS 2000, October 5 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