A scenario-driven role engineering process for functional RBAC roles

An approach for the systematic development of domain‐specific languages

“…We have chosen to use the language model driven variant of our process because the RBAC DSL is placed in a domain well known to the developers (see, e.g., [46,47,62,63,64,65]). Therefore, it was sensible for us to start with a conceptual language model which can be incrementally refined as the DSL evolves.…”

“…A role is an abstract entity which represents a certain type of subject in terms of the permissions granted to this type of subject. When modeled to represent human users, roles most often reflect the work profiles of a certain organization (see [47,63]). In its basic form, a permission consists of an operation, object tuple.…”

Towards the development of privacy-aware systems

“…The alignment of privacy artifacts can be established only using a requirements engineering methodology able to capture all the aspects demanded by privacy and data protection policies. There is evidence in the literature that Requirements Engineering can support the specification of privacy policies [51] as well as of data protection policies [52] and, in general, access control policies [80,95]. However, their drawbacks are mainly due to the underlying requirements engineering methodology.…”

“…Neumann et al [95] proposed a scenario-driven role engineering process for defining RBAC policies. This process starts by identifying usage scenarios where actions and events are seen as steps.…”

Mining Business-Relevant RBAC States through Decomposition

“…Many other authors sought to leverage business information to design roles by adopting a topdown approach such as [16,17]. These works represent pure top-down approachesthey do not consider existing access permissions.…”