Among the challenges of managing NASA's information systems is the management (that is, creation, coordination, verification, validation, and enforcement) of many different role-based access control policies and mechanisms. This paper describes an actual data federation use case that demonstrates the inefficiencies created by this challenge and presents an approach to reducing these inefficiencies using OWL. The focus is on the representation of XACML policies in DL, but the approach generalizes to other policy languages.
NASA has at least one significant information management problem: the kind,
scale, and growth-rate of its data and information is impressive and increasing.
It also has significant challenges in data discovery and in the reuse and
dissemination of unique scientific data collections. Several efforts are underway across
NASA to use semantic technologies, including RDF and OWL, to respond to
these challenges. NASA Enterprise Architects have shown considerable interest
in the use of semantic technologies [
While data integration and maintenance are implied requirements of NASA’s primary missions, they aren’t the central focus.5 This fact, and the need for fiscal responsibility, motivate the agency to use existing technology and tools for the creation, management, and enforcement of access control policies and exchange and integration of data.
Table 1 summarizes the access control policies of the constituent data sources
integrated in [
Request
Decision Data Source Payroll An approach to horizontal integration of data sources that the co-authors are piloting within NASA is the development of a “global” schema that exists in a 5 Further OMB initiatives like the Federal Transition Framework and 18 planned Federal Lines of Business further intensify NASA’s motivation to quickly solve common data exchange problems within its four primary missions in order to participate in future mandated inter-agency activities. well-defined relationship to the schema of individual data sources and the materialization of a subset of the data source data in the global schema.6 The refresh of data in the global repository occurs at intervals determined in accordance with the requirements of the information consumer and the data source’s lifecycle.7 The federated data sources discussed here are read-only from the end user’s perspective.
Integrating the data from multiple data sources presents challenges in policy management, since the data sources typically have distinct access control policies. Determining how the policies of the constituent sources align and the subsequent specification of a policy for the integrated data is a crucial aspect of this work. Formulating this alignment is a labor intensive process that is time consuming and error prone. It reduces the speed with which integrated applications can be designed and deployed and often involves personnel across organizational boundaries. The burden of the process demonstrates an undesirable tension between application deployment and security concerns. Thus, the automation of policy alignment and synthesis has the potential to increase the efficiency and security of the organization. 3
The eXtensible Access Control Markup Language (XACML)[
The XACML formalization includes resources, subjects, and actions. Considering a universe for which we seek to describe permissible activities, subjects are the entities which perpetrate such activities. Actions are a description of the nature of the activities. Resources are the independent entities that are the objects of such activity. Classes of resources, subjects, or actions can be described using general attribute value pairs, which are further discussed in section 3.2.
In its simplest form a XACML rule is a mapping from a set of subject, action, and resource tuples, called a target, to an indicator of permissibility, a decision, either Permit or Deny. Rules are aggregated in policies, which can be further aggregated into policy sets. At each aggregation of rules and policies, combining algorithms indicate the manner in which the collected decisions of the constituents yield a single decision for the aggregate. Combining algorithms are further discussed in the next section. 6 The materialization of multiple databases in a global schema is frequently called data warehousing, but that term often implies a scale or business function that is irrelevant to the discussion of data federation presented here. 7 So payroll systems are updated every two weeks, consistently; directory services are updated daily, but can be refreshed as infrequently as once per week; and technical report aggregation services are updated once or twice per year.
For reasoning purposes, [
Because a policy set may contain multiple policies and each policy may contain multiple rules, each of which may evaluate to different access control decisions, XACML needs some way of combining the decisions each makes. This is accomplished using a collection of combining algorithms, where each algorithm represents a different way of combining multiple access decisions into a single one. There are Policy Combining Algorithms and Rule Combining Algorithms which have similar semantics. For example, with the Deny-overrides algorithm, if any of the child elements return Deny, then the final result is also Deny (no matter what the other children return). The DL translation currently supports Permitoverrides8, Deny-overrides9, and First-applicable10 combining algorithms. 3.2
Attributes are the most basic unit of a XACML policy. They represent characteristics of the subject, resource, action, or environment in which the access request is made. It follows that access requests in XACML contain a list of attribute value pairs.
Consider an access control system integrated into the NASA Competency Management System. In this system, individual users are subjects, “read” and “write” are actions, and records describing NASA employees are resources. In such a system, a particular access request might contain a subject for which the role attribute has value manager. The basic building blocks described enable specification of a policy such as “permit managers write access to the CMS system and deny write access to all other users.”
Here we provide an example of a rule that returns Deny for access requests that have value write for attribute action. This rule would be a part of the policy described above. 8 If any rule evaluates to Permit, then the final decision is also Permit. 9 If any rule evaluates to Deny, then the final decision is also Deny. 10 The effect of the first rule that applies is the decision of the policy. <Rule RuleId="DefaultDenyWriteRule" Effect="Deny"> <Target> <Subjects><AnySubject/></Subjects> <Resources><AnyResource/></Resources> <Actions> <ActionMatch MatchId="function:string-equal"> <AttributeValue DataType="#string">write</AttributeValue> <ActionAttributeDesignator
AttributeId="action"
DataType="...#string"/> </ActionMatch> </Actions> </Target> </Rule>
More complex policies can be created using additional XACML features. To this end, XACML reuses several XML Schema primitive datatypes and adopts some additional datatypes useful in a network access environment. Predicates for manipulation and evaluation of these datatypes adopt a similar approach— XML data standards are adopted where feasible and new predicates are defined as necessary and useful.
The DL translation provides some datatype support for values of attributes. More specifically, it offers support for built-in and user-defined XML Schema datatypes (currently only datetime and integer). For example, one could state that age attribute can have value ≥ 18, or that it must be one of 18, 19, 20, 21. 3.3
The DL translation supports the Hierarchical Role-based Access Control Profile
of XACML [
The unsupported elements of XACML include multi-subject requests, complex attribute functions, rule conditions and some combining algorithms (see section 3.1). Some features (like complex conditions) may be impossible to analyze at development time, but there are others which we believe could be handled in the translation (some types of conditions, more expressive datatypes and the Only-one-applicable overriding algorithm) — all part of our ongoing work. 4
This section describes a very simple example policy in more detail. Initially there are two roles, Manager and Developer; one resource: Report; and two actions: read, write. The root policy set contains two policy sets which are combined using the First-applicable combining algorithm. The policy is presented in graphical form in figure 1.
The safety property for this example is that Developers cannot write to Reports. Checking the example policy against this property produces a fail, with the following counter example returned: role=Manager, role=Developer, action=write, resource=report Thus, if a requester is a member of both roles (Manager and Developer), then she can gain write access to Report. To prevent a Developer who is masquerading as a Manager from writing to Report, we use a separation of duty constraint: no user can be a member of both Manager and Developer roles at the same time.
However, the policy fails to satisfy the property even after adding the above constraint. This time, the counter example given is:
role=Developer, action=write, action=read, resource=report Apparently there is another way for a Developer to gain write access: if he tries to both read and write to Report at the same time. To prevent this from happening, we can restrict R2 such that only one value (read) is allowed for action attribute. After adding this constraint the policy satisfies the property.
The example policy also demonstrates redundancy. A policy element is redundant if removing the element does not change the behavior of the access policy. To motivate a redundancy detection service, consider rule R4 in Figure 1. R4 will always be overridden by R3, since the policy combination is First-applicable, and the target of R3 subsumes the target of R4. In a policy evaluation engine, R4 can be dropped without any consequences to the security policy. This elimination of unnecessary rules at policy design- or audit-time, could provide significant optimizations for a policy framework, both in execution efficiency and human comprehensibility. 5
Some of the policy analysis services enabled by our approach are described below. 5.1
Policy comparison is a generalized form of policy subsumption. Policy subsumption holds between two policies or policy sets, P1, P2, and a decision, α ∈ { Permit , Deny }, if P1 produces decision α whenever P2 produces decision α. Subsumption may be evaluated independently for Permit and Deny, or they may be considered together. Calculating policy subsumption is equivalent to determining DL concept subsumption.
Often knowledge of the particular requests for which the decisions differ is useful. Modifying the reasoner to generate all such instances, typically through saturation of the tableau, yields all possible requests for which the policy outcomes differ. This approach can be generalized to permit policy comparison for any decision combination.
General policy comparison is critical in a federated data environment which requires alignment of the access control policies of distinct data sources. In particular, the ability to determine the requests which yield different decisions is helpful in debugging why an individual may have a more limited view at the global data repository than at a specific constituent source. Further, using the subsumption services makes determination of the most or least restrictive policy among a set of data sources feasible, a task required when constructing a global access policy required to be as restrictive as the most restrictive of the data source policies.
Policy comparison also allows for iterative policy development because access control is often delegated at organizational or application boundaries. This creates an environment where local system and security administrators build policies to manage their users by refining a broader access policy. The comparison service allows these administrators to manipulate their policy and routinely evaluate its relationship to the broader policy and insure that changes don’t create unintended consequences.11 5.2
Policy verification is the confirmation that a policy produces an expected
decision for a given set of request characteristics. The mapping to DL reasoning is
11 Difficulties associated with managing policies in a distributed system and the
vulnerabilities to attack exposed by those difficulties are discussed in [
Policy verification services are essential in the NASA integrated data environment because they provide a mechanism to insure security policy compliance from design-time through audit and testing. 5.3
Representation of access control policies in OWL has additional benefits to the
policy author. The general applicability of OWL permits specification of policy
using terminology that exists in a broader context than the XACML document
itself. A policy can adopt terminology present in enterprise data descriptions,
common industry ontologies, and other OWL content. The benefit to the policy
author of reusing formalisms is twofold. First, it expedites the policy creation
process by avoiding repetition of already performed business process modeling
work. Second, it improves quality by allowing adoption of high-quality models
already validated in other deployments. Finally, use of OWL enables use of
DL formalisms for natural representation of many policy idioms. Such idioms
are discussed in detail in the next section. The application of OWL to policy
creation and management is discussed in [
One of the distinguishing features of our approach is that the subjects, actions and resources used in the access policies are mapped to DL concepts and roles. For example, if the policy is about managers, developers, and their interaction with reports, we can have an ontology that describes the company domain, and link the policy entities with concepts in the ontology using subclass relationships. For example, we can state that a Manager must be an Employee that is the supervisor of at least one Person:
M anager v Employee u ∃supervisorOf.P erson
Using such ontologies, we show how common policy idioms can be expressed in description logics: 1. Role hierarchies are easily captured with subclass axioms. For example ,stating that a LeadDeveloper inherits all of the access privileges of the Developer role can be expressed as:
∃role.LeadDeveloper v ∃role.Developer 2. Hierarchies on Attributes, can be captured using property hierarchies in DL.
For example, to state that if a person is a CIO of a company, that means he is also an employee of that company, we write: 3. Separation of duty constraints can be captured with disjoint axioms. To state separation of duty for two role types A and B, we use: cioOf v employeeOf
∃role.A v ¬∃role.B 4. Cardinality constraints can be expressed on any given attribute. To state that the role attribute cannot have more than k values, we can write: ≥ k role.> v ⊥ We can even specify maximum number of users that a role can have, with a combination of inverses and cardinality constraints. For example, the following says that a role cannot have more than k users:
≥ k role−.> v ⊥ 7
This paper has discussed a mechanism to represent a profile of XACML in DL
with an interest in applying it to a data federation architecture at NASA. That
mechanism has considerable applicability and extensibility within and outside
that use case. Though not discussed here in detail, XACML has a profile targeted
at representation of role based access control (RBAC)[
It is notable that although the presentation here uses XACML as the policy
language, it is not a requirement of the approach. XACML was chosen because
it is a standard language and has some industry adoption, but the approach
detailed could be applied to any similar policy language. A notable target language
is WS-Policy, a language to which DL mappings have been studied[
Finally, we reemphasize that the full expressivity of XACML is not yet
accessible in our approach. [