OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

xacml message

[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


Hi Martin,

There are 2 classes of domains that I think are relevant for policy development
and associated tools:
  1. Vocabulary domains, where, for an enterprise or an industry such as
    health care, there are a set of terms that need to have common defns
    and meaning that participants in the community impacted by the
    policies can refer to for developing and analyzing policies.
  2. Functional domains, where there are specific functional characteristics
    wrt to the policy defns that the community wants to exploit. The
    best example of this that I am aware of is a "query capability" where
    the functions that need to be implemented include finding resources
    that can be accessed by specific users, and finding the specific users
    that are capable of accessing specific resources.

The support for vocabulary domains is largely external to XACML proper,
however, the support for functional domains may well involve developing
specific policy structuring techniques that can facilitate delivery of the
needed functionality.

    Thanks,
    Rich

On 8/6/2015 6:04 PM, Martin Smith wrote:
Rich--

Thanks, and sorry about the lousy audio on my end. 

I agree it's critical to make rule creation a process that requires neither programming nor creating lots of <TAGS>. XML is fine under the covers, but the user interface has to be something the business or compliance analyst can deal with. I've always assumed this (creating analyst-friendly tools) was where IAM vendors would distinguish themselves, while maintaining as much complexity in the XACML standard as is needed for maximum functionality and rigor. 

Not sure I understand how you are thinking of "domains" for which subsets of XACML would be optimized.  Examples?? 

(When I think of domains I think of communities of interest (e.g. healthcare services, patients, doctors, and related.) And I have thought the specialization for them would be in terms of relevant attribute sets (isaDoctor, isaHealthResearcher, etc.) Or the IP or Export Control profiles!)

Regards,

Martin


On Thu, Aug 6, 2015 at 5:13 PM, rich levinson <rich.levinson@oracle.com> wrote:
Hi Martin,

additional comment:
  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:

Martin,

 

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.

 

Two-step process

 

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.

 

Hal

 

From: Martin Smith [mailto:bfc.mclean@gmail.com]
Sent: Friday, July 24, 2015 12:52 PM
Cc: XACML TC
Subject: [xacml] Note regarding 2-stage digital access policy development

 

TC Members-- I am re-posting the attached with a revised subject line so it's easier to find. (First post subject was  Re: [XACML] Proposed Agenda 23 July 2015 TC meeting -- not too informative!)

 

Martin

 

 

On Thu, Jul 23, 2015 at 3:17 PM, Martin Smith <bfc.mclean@gmail.com> wrote:

Bill, all--

 

At the end of the last TC concall I mentioned interest in getting feedback on the idea of developing digital access-control rule sets as a 2-step process. It was suggested I clarify the idea by providing something in writing.  Attached is a start on a write-up, just to provide some illustration of the idea. It is not complete, even as a first draft, but I wanted to get back to the TC with something since I had raised the matter. 

 

Given the last-minute posting I am not requesting any time on today's TC agenda, but of course response from the list is always appreciated. 

 

Regards,

 

Martin

 

 

 

 


 

--

Martin F Smith, Principal

BFC Consulting, LLC

McLean, Va 22102

703 506-0159

703 389-3224 mobile


--
Thanks, Rich

Oracle
Rich Levinson | Internet Standards Security Architect
Mobile: +1 978 5055017
Oracle Identity Management
45 Network Drive | Burlington, Massachusetts 01803

Green Oracle Oracle is committed to developing practices and products that help protect the environment




--
Martin F Smith, Principal
BFC Consulting, LLC
McLean, Va 22102
703 506-0159
703 389-3224 mobile

--
Thanks, Rich

Oracle
Rich Levinson | Internet Standards Security Architect
Mobile: +1 978 5055017
Oracle Identity Management
45 Network Drive | Burlington, Massachusetts 01803

Green
            Oracle Oracle is committed to developing practices and products that help protect the environment



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]