UML Security 2

1
UML Security - 2

• Integrating Access Control Design into the
  Software Development Process
• by
• Gerald Brose, Manuel Koch and Klaus-Peter Lohr

2
Objective and Summary

• Integrate access control into designs
• Covers most parts of the software development
  cycle.
• Integrates access control in to UML designs
• Has both permissions and prohibitions
• Has some aspects on role-based access control
• Constructs views for interfaces

3
The Protection Model
4
Protection Model Preliminaries

• Subject User
• Object entity
• Action operation, method
• Access Role In the sense of RBAC
• Principle Subject or role
• View a static typed language description for
  fine grain access control

5
Views

• Defined using view policy language.
• Static restrictions can be placed on views, such
  as limiting the roles.
• View are hierarchical, and inherence can be used
  to enhance reuse.
• Access policies are stored in descriptor files,
  and deployed together with applications

6
Other Aspects

• Shows how to map views to the CORBA component
  model, EJB.
• Authors Claim VBAC are explicit, type checked
  specifications of access policies.
• Uses digital certificates to represent role
  membership
• Have policy servers to be consulted by runtime
  systems.
• Have a deployment and management tool VBAC called
  RACOON.

7
VBAC and the Software Life-cycle
8
Enhancements to Use Cases
9
Use Case Legend

• Three actors
• Calendar owner, sub actor of
• Secretary, sub actor of
• Other.
• Calendar owner can
• Create, edit or delete singular or continuing
  meetings with others
• Can delegate meeting scheduling to secretaries

10
Use Case Legend - II

• Secretaries can
• Create singular meetings
• Create/edit continuing meetings with others
• CANNOT create continual meetings or delete any
  kind of meetings
• Others can
• View publicly available calendar.
• Notice
• Use of inheritance for reuse of specification
• Need to specify prohibitions imposed on sub actors

11
Decorating Use Case with Access Control
Requirements

• Specify actors and use cases forbidden for them
  with ltltdenygtgt associations. For eg
• update room use case must be denied for the actor
  calendar owner
• Explicitly state prohibitions per each actor in
  check boxes. For eg
• The check box in update room for the Calendar
  Owner has the statement not book a room

12
Decorated Use Case
13
Attaching notes to actors

• Informal use-case descriptions implicitly state
  allowed and denied accesses to objects (once the
  objects have been determined in the analysis
  phase)
• They are made explicit by using notes attached to
  use actors corresponding to a use case.

14
Example Notes
15
Roles in UML and VBAC

• UML definition of actor
• A coherent set roles that a set of users can play
  when interacting with a system
• An actor has one role for each use case
• Named specific behaviors of an entity
  participating in a given context
• Examples
• Secretary has roles edit entry, new entry etc.

16
VBAC Roles

• VBAC roles are more coarse grained. For eg
• Doctor, nurse, secretary.
• VBAC roles are similar to RBAC roles, but without
  conflict specifications.
• One VBAC role consists of many UML roles.
• VBAC role hierarchy follows from the
  generalization relations between actors.

17
View Diagrams

• Assumption
• Access description in use cases can be mapped to
  design diagrams.
• Authors Claim
• The ultimate goal of security policy design is a
  policy description that can be deployed together
  with the application.
• Consequently
• Suffices to map abstract system accesses to
  operations in (CORBA) interfaces.

18
The Class Diagram
19
Class Diagram

• Has one entity class and seven interface classes.
• Notice that methods and their accesses have been
  determined as , -.
• How can these details be transformed into view
  diagrams?
• View diagrams are static typed descriptions of
  access rights
• Advantage designers can check against each
  users access rights

20
View Diagram for Interface Calendar
21
View Diagram for Interface Room
22
View Policy Language

• Syntactic description of policies on views
• Can be generated from UML design diagarms used in
  this work.
• What is specified in a VPL declaration
• Roles and their hierarchies (Roles Clause)
• Roles that are allowed and denied to access the
  view (allow and denied clauses)
• What object is it controlling. (in controls
  clause)

23
Example VPL Specifications -1
24
VPL Specifications - 2
25
VPL Specifications - 3
26
Tool Support

• Any UML tool can be used to draw extended use
  cases.
• UML can be translated to XMI , and to XSL style
  sheets (hopefully to XML schema)

27
Issues with the Paper

• Access control, over-ride policies.
• Over-Specification and Inheritance Consistency
  resolution policies such as denials take
  precedence and permissions take precedence.
• Under-specification Open policies (where
  unspecified permissions are allowed) and closed
  policies (unspecified permissions are denied)
• Flow-control vs. access control