xacml — archive

[System]

Bill, thanks for making it clear how we got here (an often overlooked but important task!) The RBAC paper accurately reflects the semantics of roles as I was trying to describe them. Although it alludes to the relations between roles and classical permission groups, I did not find an explicit mention in the RBAC document that makes it clear that the propagation of rights through a hierarchy is exactly opposite for groups and roles in an unrestricted role hierarchy, i.e. a child group gets all the rights of its parent group whereas a parent role gets all the rights of its child roles. This is important from both a model and implementation perspective because it means only one or the other has to be defined at an axiomatic level, i.e. we could have a core model or implementation that speaks only of groups since all roles could be mapped back to real or virtual groups by inverting the role tree. For example the role tree Domain Admins Machine Admins Machine Users Can be mapped to the group tree Machine Users Machine Admins Domain Admins Note: This does not preclude Domain Admins from also being in some other group. I happen to like the layered approach of the RBAC model and have actually been thinking we will need to do something even more extensive. For example (this will be a bit cryptic, perhaps even incomprehensible!, I will clarify later if I get any feedback that people think I might be on to something): Assume that everything we can refer to in a policy is related to either another policy, object, subject, permission, operation on the object, security cell or condition. Use a numbering scheme with dot notation for each item above, e.g. 1.1.1.1.1 would say that policies have the ability to use policies, objects, subjects, permissions, operations, security cells and conditions at capability level 1. Policy = 0 no reference to other policies Policy = 1 reference to other policies allowed Object = 0 no reference to objects allowed Object = 1 reference to objects allowed Object = 2 reference to objects and their attributes allowed Subject = 0 no reference to subjects allowed Subject = 1 reference to users allowed Subject = 2 reference to users and groups Subject = 3 reference to users, groups, and roles Permission = 0 no reference to permissions Permission = 1 reference to allowed/not allowed Permission = 2 reference to allowed/not allowed/unknown Operations = 0 no reference to operations Operations = 1 reference to core operations read, write, execute, modify, delete Operations = 2 reference to user extended operations, e.g. play, republish Security Cells = 0 no reference to security cells Security Cells = 1 flat partition of security cells Security Cells = 2 hierarchy of security cells Conditions = 0 no reference to conditions Conditions = 1 reference to simple function calls Conditions = 2 reference to predicates containing free variables Conditions = 3 reference to predicates containing free variables referring back to other system entities 0.0.0.0.0.0.0 has no security 0.1.1.1.0.0.0 is simple ACLs naming objects and users with on/off operational constraints 0.1.1.1.1.0.0 is ACLs with operational constraints 0.1.2.1.1.0.0 is ACLs with groups (NT 4.0 security) 0.1.2.1.0.0.0 is ACLS with groups and just access allowed or disallowed (typical "legacy" web server approach) 0.1.2.1.1.2.0 early military security system that assigns security classifications to objects 1.2.3.1.2.2.3 Reuter's level of requirements (correct me if I'm wrong Dave ... if you can even follow this!). Bill, if you read this far then I assume I haven't lost my grip ;-) >