Orion - A model for authorizaton

1. Orion - A model for authorizaton By Gigi Shum and Chi-Fung Wong

2. Introduction • Database security • Protect data in the Database • Do so by restricting/determining access • Most models on authorizations thus far have been on relational databases

3. Object oriented features not found in relational database require new security mechanisms to provide access to objects in a database. • Object Oriented database features such as class inheritance, composite classes need additional rules to govern access

4. Overview • Establishes a set of relationships between objects, the user, and the authorization modes for the object • Defines rules which are used to define implicit authorizations based on explicit authorizations • Proposes authorization methods for object oriented features such as inheritance and complex objects.

5. Overview cont.. • Supports the following authorization types • Positive • Negative • Strong • Weak • Explicit • Implicit • Expands the definition and utilizes implicit authorizations • Outlines the calculation of implicit authorizations

6. Authorization Types • Positive authorization • ‘Yes’ • Negative authorization • ‘No’ • Explicit • Specifically saying if you have access • Implicit • Implying you have access • Strong • Authorization that can’t be overridden • Weak • Authorization than CAN be overridden

7. Weak and Strong Access Bases • This model defines two access bases • Weak • Strong • Both access bases include positive and negative rights • Weak authorization can be overridden allowing exceptions to be made in implicit authorization

8. Basics… • Authorizations are determined by three items • Subject (who) • Authorization Object (desired access) • Access privileges (r, w, rd, c)

9. Implicit Authorization • The core of this model • Authorization of a user for access of an object in the database implies it has other authorizations • Saves space • Don’t need to store all the explicit authorizations • Just calculate the implicit authorizations based on the minimally stored explicit authorizations

10. Implicit Authorization cont… • There is overhead in calculating implicit authorizations • May not be ‘cost effective’ if there is no need to define many authorizations on an individual object • In relational db, access is usually made on a relation (table) and not on a specific tuple (row in the table) • Therefore defining authorizations (explict or implict )for individual tuples is not very strong

11. Implicit authorizations cont… • In this model, there are implicit authorizations for subjects, objects and privileges • The number of objects in a database can be very large, so saving space by using implicit authorizations makes sense

12. How to calculate implicit authorizatons?

13. Basics cont…… • Explicit authorizations may imply authorizations along any combination of the 3 items previously listed • A group of users has write/update access on a set of objects • E.g. Group of users = the people who work at admissions and records on campus • Set of objects = student/faculty records • Implies one member from the group of users has update access on any one of the objects in the set • Also implies that any one user also has read access to an object in the set

14. Basics still cont… • Hierarchies • The authorization triplet is organized into hierarchies • Role hierarchy e.g. Government leaders . .(other leaders) . .Average citizen

15. Basics – keep going… • Role Hierarchies • Implies if Average Joe has access, President Bush will have access • Implies if President Bush doesn’t have access, Average Joe doesn’t have access • However, just because President Bush has access, doesn’t mean Average Joe will have access

16. Basics - ..and going • Access Privileges Hierarchy W>R, W>C, R>RD, C>RD W>RD

17. Authorization Object Schema (AOS) • Entities are also grouped into a hierarchal structure • Each is an authorization object type

18. Authorization Object Lattice (AOL) • A virtual structure derived from the AOS • Used to compute implicit authorizations • Each node belongs to one authorization type • Implication links to the set of authorization object at the next lower level (e.g. setof-instances) or only one implication link to the next lower level (e.g class)

19. Authorization Object Lattice (AOL) cont… • Implication links to the set of authorization object at the next lower level (e.g. setof-instances – links to all instance authorization objects of the class) • Or only one implication link to the next lower level (e.g class – links to only one setof-instances authorization object)

20. Authorization Association Matrix (AAM) • Note how authorization types propagate through the AOL • A.down • E.g. W&R access on an object high in the hierarchy implies you have W & R access on the set of authorization objects at the next lower level • A.up • E.g. RD of an instance means RD on a class, RD on a class means RD on a Database where the class resides • A.Nil • Having a create access on one thing does not imply that you have create access on anything else

21. The authorizations are specified by the users who have authorization for a given access privilege on a object. They can grant authorizations to other users. When they explicitly grant authorizations, implicit authorizations based on the implication relationships between the access privileges and the rules of propagation are automatically given.

22. Authorization Object Schema for an Object Oriented Database

23. Other implications from this model • A read or write privilege on a class of a inheritance implies R/W access on all the classes in the inheritance hierarchy • However, it does allow for the option that no authorization will be given to the subclass • This is to protect data in the subclass from other people that might have access to the parent class.

24. Other implications cont… • Authorization on a composite class (class made up of other classes) means implicit authorization on the component classes • Note: this is for one instance only, not all instances of the component classes • Partial and total authorizations: • A total write access on a component of a composite class means total write access on all descendents and partial write access on all ancestors • A partial read access on a component of a composite class means the same privileges on the top level components

25. Main points of this model… • Usage of implicit authorizations • Usage of explicit negative authorizations • Usage of weak authorizations as exceptions to the implicit authorizations • Extends the authorization models of today to object oriented databases • Lacking object and subject classification for mandatory access control.