http://portal.acm.org/citation.cfm?id=545186.545191
http://doi.acm.org/10.1145/545186.545191
- 2002, so its not -very- recent
- They list reasons/motivations for the formalism early on. (1) prove properties of a given specification (2) compare different AC models (3) predict system behavior by combining diff. policies
- Formalizes RBAC using a graph transformation language [Rozenberg 1997]
- Provides static and dynamic consistency conditions, and has an executable specification with existing tools
- "A graph represents a state of a system... state changes are specified by graph transformation rules... a rule is given by a graph morphism" -- The CPP does not really have states or state changes, its a static analysis so I'm guessing an approach like this isn't a great match.
- Just thinking here: one approach if we continue down the use of our own langague is to use transformations to build up the system 1 policy at a time. Each transformation would have to ensure the system was in compliance. Oh there are so many different options like that though. Would the graph notate the policy, or the system, or both? Would transformations show the evolution of the system as components are added/removed, the change in state as it executes, the change in policies? Or would there even need to be graph transformations? Too many questions, more background research is needed.
- "The left hand side of the rule add to role contains additionally a dashed edge between the u and the r node. This dashed edge represents a negative application condition"
- "The nodes of the rule add to role do not carry labels. This representation for a rule is intended as a pattern for a whole set of rules" -- this seems pretty beneficial, the ability for the language to have patterns which can be applied to specific instanciations
- Edge Labels, absence of labels
- Edge (connected line or dashed line)
- Node names, shapes, filled or open, colors
- Transformations, rules, actions, activations
Posts
0 comments:
Post a Comment