1 / 30

Inheritance Properties of Role Hierarchies

Inheritance Properties of Role Hierarchies. Presented by Dustin Burke. About Me. Senior in Computer Science (4 th Year) Specializing in Graphics and Visualization Graduating in May, 2008 Lived in Atlanta area my entire life Travel for roller coasters. Outline.

frey
Download Presentation

Inheritance Properties of Role Hierarchies

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. Inheritance Properties of Role Hierarchies Presented by Dustin Burke

  2. About Me • Senior in Computer Science (4th Year) • Specializing in Graphics and Visualization • Graduating in May, 2008 • Lived in Atlanta area my entire life • Travel for roller coasters

  3. Outline • What are roles and why are they important? • Model Elements • Mappings & Relations • Static and Dynamic Properties • Role Hierarchies • Implications

  4. Role Based Access Control • Role - is an organizational identity that defines a set of allowable actions for an authorized user • RBAC mechanisms rely on role constructs to mediate a user’s access to computational resources • Role hierarchy – overall set of capability relationships which can be represented as a directed acyclic graph

  5. Static vs. Dynamic • Properties of this model fall into either a static or a dynamic category • Static – deals mainly with constraints on role membership • Dynamic – deals with constraints on role activation

  6. Model Elements • User – people who use the system • Subject – active entities of the system operating within roles on behalf of users • Role –named duties within an organization • Operation – set of access modes permitted • Object – passive entities protected from unauthorized use • Permission – set of ordered operation/object pairs

  7. Relations

  8. Permissions • Ternary relationship between Role, Operation, and Object is broken down • Conforms with privileges found in present day information systems

  9. Permissions • Can represent a broad range of access controls • Basic read/write/execute rights on a file • Administrative rights for OS commands • Depends on context

  10. Mapping & Relations • More specific mappings refine the general relationships in the previous diagrams • authorized-roles[u] • Roles authorized for user u • authorized-permissions[i] • Permissions authorized for role i • active-user[x] • User u associated with subject x • active-roles[x] • Roles in which a subject x is active

  11. Static Properties • Properties of the model that do not involve either the Subject component or mappings from Subject to other basic components • Apply early, at role authorization, and through role activation • Very strong • Include cardinality, separation of duty, and operational separation of duty

  12. Cardinality • membership-limit[i] • Maximum number of users that can be authorized to a role • authorized-members[i] • Number of users authorized a given role

  13. Static Separation of Duty • Responsibilities split to prevent collusion • Group of roles are mutually exclusive of one another with regard to authorization • User may only be authorized to one A B C D Not in SSD Member of SSD

  14. Static Operational Separation of Duty • Business tasks are composed of multiple operations • No single user can be authorized one or more roles having permissions involved in an SOSD User 01010 <A,B> not in SOSD <B,D> not in SOSD <A,C> in SOSD D A C B

  15. Dynamic Properties • Complement static properties • Weaker than static • Applied at role activation and not checked at authentication • Also offers degrees of flexibility • Often used in conjunction with static properties • Include role activation, cardinality, separation of duty, and operational separation of duty

  16. Dynamic Properties • exec: Subject × Operation × Object • True iff subject can perform operation on object • active-membership-limit[i] • active-members[i] • Permitted action – subject can perform an operation on an object iff the subject is acting within an active role authorized that permission

  17. Role Activation • A subject cannot be active in a role it does not have authorization for • Active roles must be a subset of authorized roles Roles: A, B, C, D, E For Subject z to have A or B in its active roles, they must first be included in its authorized roles

  18. Dynamic Cardinality • Number of users active in a role can never exceed the dynamic capacity • More desirable than static because it is maintained at activation as opposed to authorization • For example: a role with capacity of one would ensure consecutive use of capabilities

  19. Dynamic Separation of Duty • Very similar to Static Separation of Duty • Memory-less property • Has no history of activation kept for user • Prevents simultaneous activations by a user but does not safeguard against consecutive activation • Not appropriate in some environments User u requests to be active in A and B while <A,B> is in DSD; rejected User u requests to be active in A; allowed User u requests to be active in B; allowed

  20. Dynamic Operational Separation of Duty • Group of permissions may be designated as mutually exclusive with regard to roles activated by a subject • As with DSD, memory-less

  21. Role Hierarchy • A role may be defined in terms of one or more other roles • And can include additional characteristics • Automatically takes on or inherits the collective characteristics of roles • Containment is recursive

  22. Role Hierarchy • Substitution of role instances

  23. Effective Roles • Include given role plus set of roles contained by that role • Can also be related to role authorization • A user is authorized to perform tasks based on its roles as well as its roles’ roles and its roles’ roles’ roles and its roles’ roles’ roles’ roles and… • Containment is not reflexive but is transitive • Role i is not in the subset of i • If j is a subset of i and k is a subset of j, then j is a subset of i

  24. Role Hierarchy Implications • Containing roles accumulate not only the capabilities of contained roles, but constraints and separations of duty relationships • Permitted Actions are expanded to include those privileges associated with effective roles

  25. More Implications • Cardinality Inheritance: a containing role must be assigned a membership limit less than or equal to that of any contained role Role A Max: ? Role A would be given a capacity of the minimum of its contained roles. 7 from C. B: 15 D: 25 C: 7

  26. Separation of Duty Hierarchical Consistency • Separation of duty relationship cannot exist between roles that have a containment relation between them or are contained by another role in common (common heir) C <A,B> is a member of SSD But since C inherits both A and B, <A,B> is no longer a member of SSD A B

  27. Separation of Duty Inheritance • If one role contains another role that has an SD relationship with a third role, then the containing role also has an SD relationship with the third role A If <B,C> is a member of SSD, and A inherits B, then <A,C> is also a member of SSD C B

  28. Summary

  29. Paper • Inheritance Properties of Role Hierarchies • W. A. Jansen • National Institute of Standards and Technology

  30. Questions?

More Related