OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

xacml message

[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