[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: RE: Another Group - Role Distinction? + LOTS MORE
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 ;-) > -----Original Message----- > From: bill parducci [mailto:bill@parducci.net] > Sent: Wednesday, August 01, 2001 6:47 AM > To: 'xacml@lists.oasis-open.org' > Subject: Re: Another Group - Role Distinction? > > > in scanning through the rbac doc, i agree with your > assessment. however > -- just for background purposes -- the snippet below is a > remnant from a > thread that was started during the f2f discussing the statement made > there that 'groups and roles are the same thing'. implementationally > this is likely to be the case, but the topic kinda spiraled down into > the realm of the techno-pedantic as we struggled to achieve the proper > wording/example to make our point (in my case that they are > not the same > thing). i think that this is why the thread may have seemed some > somewhat bizarre when you first came across it. > > again, none of this takes away from the value of the rbac stuff, it's > just that i wanted to clarify how we got to this point for those that > think we might have started to lose our grip on the twig :o) > > b > > Hal Lockhart wrote: > > > > I will take this opportunity to post the NIST RBAC paper, as > > www.list.gmu.edu seems to still be down. > > > > I believe what Simon is describing is what they call Restricted and > > Unrestricted Hierarchies. > > > > Hal > > > > > -----Original Message----- > > > From: Simon Y. Blackwell [mailto:sblackwell@psoom.com] > > > Sent: Friday, July 27, 2001 6:59 PM > > > To: 'xacml@lists.oasis-open.org' > > > Subject: Another Group - Role Distinction? > > > > > > > > > Is it the case that groups propagate "up" whereas roles > > > propagate "down" for > > > security purposes? > > > > > > For example: > > > > > > humans is a subgroup primates > > > X is a member of humans > > > ---------------- > > > X is a member of primates = True > > > > > > humans is a subgroup primates > > > X is a member of primates > > > ----------------- > > > X is a member of humans = Unknown > > > > > > junior auditor is a child-role of senior auditor > > > X can play role junior auditor > > > ----------------- > > > X can play role senior auditor = Unknown > > > > > > junior auditor is a child-role of senior auditor > > > X can play role senior auditor > > > ----------------- > > > X can play role junior auditor = True > > > > > > > > > > > > Simon Y. Blackwell > > > CTO > > > Psoom, Inc. > > > Voice & Fax: 415-762-9787 > > > > > > > > > ------------------------------------------------------------------ > > > To unsubscribe from this elist send a message with the single word > > > "unsubscribe" in the body to: xacml-request@lists.oasis-open.org > > > > > > > > -------------------------------------------------------------- > ---------- > > Name: rbac-nist.pdf > > rbac-nist.pdf Type: Portable Document Format > (application/pdf) > > Encoding: BASE64 > > Download Status: Not downloaded with message > > ------------------------------------------------------------------ > To unsubscribe from this elist send a message with the single word > "unsubscribe" in the body to: xacml-request@lists.oasis-open.org >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC