Patterns for access control

1. Patterns for access control E.B. Fernandez

2. Access control models • An access control model defines who can access what and in what manner in a system • Some secure design methodologies start from use cases and from them a conceptual model is developed. Security constraints are then defined in the conceptual model. The most important constraints are related to access control

3. Many access control models • There are many models for access control, mostly variations of some basic models and it is confusing for a software developer to select an appropriate model for her application • Access control models generally represent a few types of security policies, e.g. “rights are assigned to roles”, and provide a formalization of these policies using some ad hoc notation • Four basic access control models are commonly used and they may be extended to include other aspects • Access control models can be defined for different architectural levels, including application, database systems, operating systems, and firewalls • Some of them apply to any type of systems while some are specialized, e.g. for distributed systems.

4. Model dimensions • Access control models fall into two basic categories: mandatory models (MAC), where users’ rights are defined by administrators and data may be labeled to indicate its sensitivity, and discretionary (DAC), where users may administer the data items they create and own • In a MAC model users and data are classified by administrators and the system applies a setoff built-in rules that users cannot circumvent • In a DAC model, there is no clear separation of use and administration; users can be owners of the data they create and act as their administrators • Orthogonal to this classification, there are several models for access control to information that differ on how they define and enforce their policies

5. Basic models for access control • The Multilevel model organizes the data using security levels. This model is usually implemented as a mandatory model where its entities are labeled indicating their levels. This model is able to reach a high degree of security, although it can be too rigid for some applications. • The Access Matrix describes access by subjects (actors, entities) to protected objects (data, resources) in specific ways (access types). It is more flexible than the multilevel model and it can be made even more flexible and precise using predicates and other extensions. It is intrinsically a discretionary model in which users own the data objects and may grant access to other subjects. This model is usually implemented using Access Control Lists (lists of the subjects that can access a given object) or Capabilities (tickets that allow a process to access some objects). • Role-Based Access Control (RBAC), collects users into roles based on their tasks or functions and assigns rights to each role. RBAC has been extended and combined in many ways. • Attribute-Based Access Control (ABAC). This model controls access based on properties of subjects or objects. It is used in environments where some subjects may not be pre-registered

6. Many variants • While these basic models may be useful for specific domains or applications, they are not flexible enough for the full range of policies present in some of these applications • A large variety of ad hoc RBAC variations that have been proposed; most of which add specialized policies to a basic RBAC • For example, some models have added content or context-dependent access, delegation, role hierarchies, task-based access, and relationships between role entities • All these models effectively incorporate a set of built-in access control policies and cannot handle situations not considered by these policies

7. Confusion for the designer • All these models present a bewildering set of options to the designer, who has problems deciding which model to use • The result in practice is that only basic models are used and the power of more advanced models is thus lost • We try to clarify this panorama here through the use of patterns • We use pattern diagrams to make clear the pattern space and help in their selection • A subproduct is the analysis of which patterns are available for use and which need to be written • Pattern maps are also useful to perform semi-automatic model transformations

8. What is a pattern? • A requirement for a pattern is that the solution it describes has been used in at least three real systems • This is consistent with the idea of patterns as best practices • However, a pattern can also describe solutions that have not been used (or have been used only once) but appear useful for several situations • Because of this, we include here both types: good practices patterns and useful solutions patterns • We consider more important their genericity

9. Structure of models • Access control models have two aspects: a definition of a set of rules specifying the valid accesses (some of them may be implicit), and an enforcement mechanism that intercepts access requests from users or processes and determines if the request is valid • The main difference between models is on the way they define their rules, so it makes sense to separate the enforcement mechanism • For each type of models we provide separate patterns for rules and only one pattern for enforcement.

10. Organizing the models • Pattern diagrams can help the designer in the selection of an appropriate model • Starting from a basic Authorization (Access Matrix) pattern we can add elements • The basic access matrix defines rights for individual subjects to access resources

11. Access matrix authorization rules • Basic rule ( s, o, t ) , where s is a subject (active entity), t is an access type, and o is an object • Extended rule ( s, o , t , p, f) , where p is a predicate (access condition or guard) and f is a copy flag • This, and the other models, can be described by patterns

12. Authorization/Access Matrix

13. Patterns derived from the Access Matrix

14. Reference Monitor • Each request for resources must be intercepted and evaluated for authorized access • Abstract concept, implemented as memory access manager, file permission checks, CORBA adapters, etc.

16. Analyze elements of the access matrix • Understand function of each element: subject, object, access type • Consider administrative approaches (MAC and DAC) • Start from a general pattern that defines structure of authorization rules: Policy-Based Access Control

18. We can expand each branch of the big pattern to focus on some specific aspects and analyze better the pattern relationships • The initial pattern diagram could have been obtained in this way

19. Policies and sessions

20. Growing models from simpler models • Each pattern can be augmented with new features to produce a new variety of models • The next figure shows the basic RBAC pattern, where users are assigned to roles and roles are given rights • The NIST standard adds the concept of session and a simple role hierarchy • The next figure shows a model of RBAC beyond the NIST standard where in addition we have object/resource hierarchies where the hierarchies are recursive (described by the Composite pattern)

22. NIST model with composite hierarchies

23. A more advanced RBAC model

24. Distributed systems • The nature of distributed systems implies that a subject does not need to be known in advance by the system in order to request access to a resource • The use of credentials including attributes may be sufficient to trust a subject. • In the next diagram, traditional models, such as the Access Matrix and RBAC (Role-Based Access Control), are represented along with Attribute-Based Access control and Policy-Based Access control • All of the models use a Reference Monitor to enforce access decisions • ACL (Access Control List) and Capability are implementation-oriented patterns; they implement the Access Matrix or RBAC model • For web services, XACML (eXtensible Access Control Markup Language) Access Control Evaluation implements the Attribute-Based Access control pattern and the Policy-Based Access control pattern, and the XACML Policy Language implements the Policy-Based Access control pattern • The SAML Authorization Assertion is a kind of Capability.

25. Patterns for distributed systems

26. More complex models • With these basic units we can compose more complex, implementation-oriented AC systems • Policy-based access control defines access evaluation based on general policies stored in some repository • Depending on the objects, rights are defined by administrators or users, the policies may define a MAC or DAC model, respectively • Policy-based access control uses a reference Monitor for its enforcement functions and a Policy pattern that defines the general structure of each policy • Policy-based access control may be specialized to implement models such as the Access Matrix, RBAC, or ABAC by convenient adaptation of the policy structure.

27. Policy-Based access control • The Policy-Based Access Control pattern decides if a subject is authorized to access an object according to policies defined in a central policy repository. • Context : We consider centralized or distributed systems with a large number of resources (objects). A large number of subjects may access those objects. Some rules are defined to control access to objects. The rules defined by the organization are typically designed by different actors (technical, organizational, legal, etc), and each set of rules designed by a specific policy designer can concern overlapping sets of objects and/or subjects. We assume that access requests come from authenticated subjects.

29. Models through analogies • We can build security models through analogies when two standards or regulations have similar types of policies • We can convert a HIPAA model into a Sarbanes/Oxley model

31. Moving to SOX • The Patient record can become a Financial record, the Patient becomes an Investor, the doctor is now a Broker • This approach simplifies the task of building pattern catalogs and makes it easier for users to remember what patterns to use in a given situation.

32. A SOX model

33. Conclusions • We can navigate the pattern diagram because patterns are composable, i.e. adding a feature (perhaps embodied by another pattern) produces a new pattern with extra features • Using this approach we could not only clarify the relationships of AC models but it lead us also to discover the need for new security patterns: Subject, Object, Labeled security, DAC, MAC • In order to apply this approach one needs: A good catalog of security patterns to let designers find the required solution to each security restriction A classification of patterns according to their security concerns and architectural level