[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [xacml] Note regarding 2-stage digital access policy development
rich: (after mtg (was struggling w internet connection, ow would have brought up)): experience w openaz showed that there needs to be "easier" ways to represent policies than pure xml-based xacml. openaz was not the first nor only project to come to this conclusion, but it is an example w which I am very familiar. however, rather than to replace xacml, what has been found is that it is reasonable to come up w representational subsets of xacml, or what might be considered a "domain-specific" representation or "profile" of xacml. what one may then do is develop a parser of the simplified language that will translate the profile into pure xacml. this enables us to maintain a domain-independent representation of policy that addresses all domains rather than being constrained by some domain-specific requirement for which pure xacml may not be effectively optimized.On 8/6/2015 3:25 PM, Hal Lockhart wrote:
Thank you for posting this. The subject of creating policies is always of interest to this TC. I have somewhat of a different perspective on some of the issues you have raised. I hope you will take them in the spirit of exploring together this problem space rather than as any kind of criticism. I could write a lot more about each of the ideas below. I will try to keep this short to stimulate discussion. I will try to express the essence of each idea.
I don’t see policy development as a 2-step process, nor do I agree with the implied idea that there are two easily distinguishable categories of sources for all policies. I do agree that there are multiple steps and multiple sources, so this may not seem to be a very important issue. However, I believe that if you try to develop a strict 2-step process and use a distinct representation (language) for each step you will have difficulties. In particular I expect you will end up having to make a lot of arbitrary decisions that other reasonable people would decide differently.
As an example of what I have in mind consider these examples. Clearly policies like “Minors are not allowed to see Adult material.” “PII may only be used for the purposes identified when it was collected” and “Business records must be retained for a specified period of time.” all would likely devolve fairly directly from law or regulation. In contrast, details such as Resource Identifiers, the spelling of Subject Attributes and their legal values are details which are specific to the local environment and were most likely created arbitrarily by other people.
However I believe much or most of policy will not fall in either category, but will consist of things which must be done to effectively enforce law or policy, but represent organizational decisions about how to conduct day-to-day operations, which must be done in some way, but is likely to be done differently in different organizations or even in the same organization at different times.
Here is an example of the kind of thing I am thinking about. Consider how the work of Admin’s is divided up. Some organizations will let everybody do everything. (Perhaps because there is only one person.) Others will divide things in functional areas (new users, access policy, user attributes, server configuration, etc.) others may organize it by subsystems (production, engineering, finance, marketing, etc.) still others some combination of these. Policy will specify the categories and requests allowed, but it is neither derived directly from above, nor is a configuration detail. Even if you don’t agree with my specific case, I still believe that a strict separation into 2 categories will not succeed.
As far as the larger question of whether it is possible to create a single process or even a framework for creating policy that is applicable across organizations, I am keeping an open mind, at least to the extent that I am participating in this discussion.
Attribute Semantics and Syntax
When we began defining XACML in 2001 there were those who advocated an approach which involved creating a data model or other semantic structure as a precondition of writing policies. Other policy languages have used this approach. What this TC decided was that we wanted a language which could be used “right out of the box” without requiring a lot of upfront work before you can write a policy. Thus the policy language only requires the things which are essential (id, category and datatype) and optionally Issuer. I think the notion we had was that people would be able to create some policies almost immediately and start getting benefits from its use, while over time developing more detail and more rigor around the use and sources of the needed attributes.
I think it would be a mistake to make it a precondition for a Federation that everyone first settle on the same attributes and values spelled the same way and with identical semantics. I think it is preferable to add IDPs incrementally and adjust policy as you go along. If a new IDP is not recording some attribute currently it makes sense to follow a standard scheme when adding it. But if an IDP has the same information in a slightly different form, the flexibility of XACML lets us define a compound test which checks the Issuer (for example) and performs different tests according to the distinct semantics. An alternative approach would be to use the context handler to “fix up” the data to the standard format. I don’t like this as well because it make the policy opaque and could lead to errors, but it is certainly feasible.
High level policy in natural language
I think the idea of using natural language to express high level policies in a rigorous way is a mistake and will lead you to a blind alley. I was particularly struck by the phrase “Because the disambiguation of natural-language policies is simpler and less contentious…” Disambiguation of natural language is one of the toughest unsolved problems in computer science. Today in fields such as International or Contract Law, attorneys and judges are paid hundreds of dollars per hour and spend months debating the meaning specific phrases in laws, regulations and contracts. In fact, any practicing politician knows that a tiny bit of deliberate ambiguity is often the best way to get agreement when the parties negotiating the original text are close, but not quite in perfect agreement.
This all applies to previously written text which must be interpreted accurately. Creating a structured language with a specific vocabulary and precisely defined semantics is another matter. If such a language consisted of mostly English language words and a syntax which was not too intimidating, it might be easier for more people to learn and use, or at least more people would be willing to give it a try.
Such a language could not necessarily be evaluated by a PDP, but it could be designed to be subject to semantic analysis. This might provide value in terms of assurance that the policies correspond to the dictates of law and regulation.
However, I don’t think it is necessary to create an entirely new language to do this. The essence of the XACML language is not the XML representation, but its precisely defined semantics. For example, Alfa has been developed to capture the semantics of XACML in a easier to understand form. It also has been proposed that we develop a JSON syntax for the same semantic. It would not be hard to develop an English-like representation of the language. In fact some experimental work has been done in this area by David Chadwick and others.
I believe you could create initial policies which would capture the essence of policy at the level of abstraction found in the laws and regulations that the policies are intended to implement. Then the details could be filled in as the deployment-specific information becomes available.
One simple way to do this in XACML (there are probably others) would be to cite functions which perform a needed test without bothering to specify how exactly the test is done. For example, we might specify in a policy a function called IsAdult(). This function would notionally determine if the Subject was of legal age without specifying any details like what attribute contains the age or what the local legal age is.
Because this approach retains the existing syntax of XACML (or could be expressed in some new English-language variant) it could be analyzed by a semantic analysis program even before the details have been specified. The tool would simply announce (for example) that for some access to be allowed, IsAdult() must be true. Later, the function could actually be implemented perform the appropriate test or instead, a preprocessor could replace the function call with some policy logic to perform the test.
The result could be a policy definition process which features what is called in Architecture “gradual stiffening”. (see A Pattern Language, Alexander, et al) The idea is that you do not produce the policy in final form right away, but rather an approximate form which is gradually refined.
Rich Levinson | Internet Standards Security Architect
Mobile: +1 978 5055017
Oracle Identity Management
45 Network Drive | Burlington, Massachusetts 01803
Oracle is committed to developing practices and products that help protect the environment