Our secure software architecture methodology focuses on architectural access control, integrating concepts in access control models into the base xADL architecture description language to form the Secure xADL language.
Access Control Models
Our approach supports multiple security models that are being widely used in practice. The classic access control model is the dominant security enforcement mechanism. In this model, a system contains a set of subjects that has permissions and a set of objects (also called resources) on which these permissions can be exercised. An access matrix specifies what permission a subject has on a particular object. The rows of the matrix correspond to the subjects, the columns correspond to the objects, and each cell lists the allowed permissions that the subject has over the object.
The more recent role-based access control model and the trust management model can be viewed as extensions to this basic access control model. The role-based model introduces the concept of roles as an indirection to organize the permissions assignments to subjects. Instead of assigning permissions directly to subjects, the permissions are assigned to roles. The trust management model provides a decentralized approach to manage subjects and delegate permissions. Since it is difficult to set up a centrally managed repository of subjects in a decentralized environment, trust management models use the attributes of subjects to identify them, and each local subject can check these attributes based on the information that is present at the local subject. The subjects can delegate permissions between each other. Several efforts have been made to provide a more unified view of these models.
Secure xADL: Subject, Principal, Resource, Permission, Privilege, Safeguard, Policy
Inspired by such a unified view, we introduce the following core concepts that are necessary to model access control at the architecture level: subject, principal, resource, privilege, safeguard, and policy. We extend the base xADL language with these concepts to get a new language, Secure xADL. The syntax of Secure xADL is described in this xADL schema. To the best of our knowledge, this is the first effort to model these security concepts directly in an architectural description language.
A subject is the user on whose behalf software executes. Subject is a key concept in security, but it is missing from traditional software architectures. Traditional software architecture generally assumes that a) all of its components and connectors execute under the same subject, b) this subject can be determined at design time, c) it will not change during runtime, either advertently or intentionally, and d) even if there is a change, it has no impact on the software architecture. As a result, there is no modeling facility to capture allowed subjects of architectural components and connectors. We extend the basic component and connector constructs with the subject for which they perform.
A subject can take multiple principals. Essentially, principals encapsulate the credentials a subject possess to acquire permissions. In the classic access control model, the principal is synonymous with subject, directly designating the identity of the subject. In the role-based access control model, a principal can be a role that the subject takes. And since a subject can assume multiple roles, it can possess several principals. In the trust management model, a principal can be the public key credentials that a subject possesses. Principals provide indirection and abstraction necessary for more advanced access control models.
A resource is an entity whose access should be protected. For example, a read-only file should not be modified, the password database can only be changed by administrators, and a privileged port can only be opened by the root user. Traditionally such resources are passive, and they are accessed by active software components operating for different subjects. In a software architecture model, resources can also be active. That is, the software components and connectors themselves are resources whose access should be protected. Such an active view is lacking in traditional architectural modeling. Explicitly enabling this view can give architects more analysis and design powers to improve assurance.
Permissions describes a possible operation on an object. Another important security feature that is missing from traditional ADLs is privilege, which describe what permissions a component possess depending on the executing subjects. We model two types of privileges, corresponding to the two types of resources. The first type handles passive resources, such as which subject has read/write access to which files. The second type handles active resources. These privileges include architecturally important privileges, such as instantiation and destruction of architectural constituents, connection of components with connectors, execution, and reading and writing of architecturally critical information.
A corresponding notion is safeguard, which are permissions that are required to access the interfaces of the protected components and connectors. A safeguard attached to a component or a connector specifies what privileges other components and connectors should possess before they can access the protected component or connector.
A policy ties all above mentioned concepts together. It specifies what privileges a subject should have to access resources protected by safeguards. It is the foundation for making access control decisions. We adopt the eXtensible Access Control Markup Language (XACML) as the basis for our architectural security policy modeling. The language is based on XML, which makes it a natural fit for our own XML-based ADL. The language is extensible. Currently it has a core that specifies the classic access control model, and a profile for role-based access control. A profile for trust management is also in development. This modular approach makes the language evolvable, just like our own xADL modular approach.
An Algorithm to Check Architectural Access Control
We present an algorithm that can check whether an architectural access in a software architecture description should be granted or denied. It first checks whether the accessing interface and the accessed interface is connected in the architecture topology. If not, the algorithm then denies the architectural access. If they are connected, the algorithm proceeds to find the interface in the path that is nearest to the accessed interface. If the accessing interface and the accessed interface are directly connected, this direct accessing interface is the same as the accessing interface. Then, the privileges of the direct accessing interface are accumulated, using various contexts, so are the safeguards and policies of the accessed interface. If a policy is explicitly specified by the architect, then the policy is consulted to decide whether the accumulated privileges are sufficient for the access. If there is no explicit policy, then the access is granted if the accumulated privileges contain the accumulated safeguards as a subset.
Contexts of Architectural Access Control
From an architectural modeling viewpoint, when components and connectors are making security decisions, the decisions might be based on entities other than the decision maker and the protected resource. We use context to designate those relationships involved in architectural access control. More specifically, the context can include 1) the nearby components and connectors of the component and the connector, 2) the explicitly modeled sub-architecture that contains the component and the connector, 3) the type of the component and the connector, and 4) the global architecture. Modeling the security context makes the architectural security implications more explicit, and any architectural changes that impact security become more apparent.
Such context should be integrated in the policy modeling. XACML provides the concept of policy combination, which combines several policies into an integrated policy set. Different policy combination algorithms, such as permit-override and deny-override, are provided as part of the standard, and we extend them with structure-override and type-override, which gives the structure and the type final authority on granting permissions. The XACML framework, combined with our explicit modeling of architectural context, supplies necessary flexibility in modeling architecture security.
A Connector-Centric Approach
Connectors play a key role in our approach. They regulate and enforce the security properties specified by components, decide what subjects the connected components are executing for, inspect whether components have sufficient privileges to communicate through the connectors, and have potentials to provide secure interaction between insecure components. Connectors can be composite connectors, where a composite connector combines several connectors together into a large connector to achieve a composite security policy.
Using connectors to regulate and enforce security policies and leveraging advanced connector capabilities will facilitate supporting multiple security models. These advanced connector capabilities include the reflective architectural derivation of connectors from component specifications, composing connectors from existing connectors, and replacing one connector with another connector.
Architectural Operations
We identify three types of run-time architectural operations: architectural instantiation, which creates the components and connectors based on the architecture description; architectural connection, which binds the interfaces of components and connectors together; and message routing for event-based architecture styles
A connector is also vital in these architectural operations. It participates in deciding whether architectural connections should be made, by rejecting inappropriate connections when the architecture manager consults it before the connection; and it assists in determining whether a message should be routed to the intended recipient, by discarding improper messages routed through it. The secure connector makes these decisions based on the specified security policies and the message. It can inspect both the architectural properties of the message and the content of the message to make a decision on delivery.
Tool Support
Tool support is included as part of our base architecture development environment, ArchStudio. The tools include an editor to describe a secure software architecture written in Secure xADL, a checker to apply the access control analysis algorithm, and an execution engine to execute secure architectural operations for event-based software architectures.
Thesis and Presentations
A more detailed description of the Connector-Centric Approach to Architectural Access Control can be found in my thesis. A summary presentation is also available. Here is a flyer. And here is a larger poster.
