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] Attributes of Relations

For the purposes of IPC, I believe our proposal for additional attributes which will trigger a PIP query (to SQL and/or LDAP) are sufficient for the present.  I don't see a need for extensively changing the core at this point.  Some of the ideas that have been discussed in this thread could provide the basis for post-3.0 work; for example, having a standardized query interface for RDF would be useful.

-----Original Message-----
From: xacml@lists.oasis-open.org [mailto:xacml@lists.oasis-open.org] On Behalf Of Erik Rissanen
Sent: Thursday, December 20, 2012 1:40 AM
To: Steven Legg
Cc: xacml@lists.oasis-open.org
Subject: Re: [xacml] Attributes of Relations

Hi Steven,

Regarding a PIP to query the context handler, it is something which is not really made explicit in the XACML architecture diagram due to lack of granularity, but it is implied. One issue is that what one means with the term PIP. Is that the remote data source, that is, the actual SQL database, only? That one of course does not query the context handler, but the "PIP connector", which is part of the context handler perhaps depending how one would elaborate the finer details in the XACML architecture, certainly has access to the attribute values of the abstract request context. It will use these as key values in its queries to the database, or it would be entirely incapable of the most basic remote attribute value retrieval.

Anyway, if you want something standardized, I would instead of re-inventing the wheel, look into defining a query interface from XACML to something like RDF, which is capable of expressing these types of relations and has a powerful query language and implementations are available, both commercially and open source.

I might be mistaken, but my gut feeling is that you underestimate the amount of stuff needed if you consider only this one use case. Once you have multiple different relations which are interconnected and you want to match on several fields in different ways and do joins between the relations, an iterator just is not enough.

Best regards,

On 2012-12-20 04:36, Steven Legg wrote:
> Hi Erik,
> On 19/12/2012 7:03 PM, Erik Rissanen wrote:
>> Hi Steven,
>> Yes, that is my proposal. See inline for responses to your concerns.
>> On 2012-12-19 00:44, Steven Legg wrote:
>>> Hi Erik,
>>> On 18/12/2012 2:18 AM, Erik Rissanen wrote:
>>>> Hi Steven,
>>>> My point in my email was that you cannot just flatten attributes
>>>> like that, as you describe yourself, but also that I don't think it
>>>> is worth doing in XACML.
>>>> One option is to extend XACML. There are multiple ways to do that.
>>>> One is to define a tuple/relation
>>>> datatype and operators on it, which I think is a relatively nice
>>>> and clean solution. Another one is what you propose is to iterate
>>>> over categories, which I don't quite like as much since it appears
>>>> more kludgy than well established relational algebra on tuples. We
>>>> could debate this...
>>>> However, you can also handle a requirement like this in a PIP, in
>>>> which case you do not need any changes to XACML.
>>>> Given that, we could define these extensions into XACML, but I have
>>>> doubts about what the value of this would be since it complicates
>>>> the XACML language, making XACML harder to learn and implement. And
>>>> since these operators/iterators are already available in commonly
>>>> used PIP backends such as SQL and LDAP, so the XACML industry would
>>>> essentially be re-inventing these features into the XACML language,
>>>> although every organization already has easy access to solve these
>>>> use cases using the existing XACML spec and PIPs.
>>> You really need to describe your thinking in more detail.
>>> Since the PIP only supplies attributes, my best guess is that you
>>> expect to use XACML attribute values, typically of the boolean
>>> data-type, as surrogates for the result of SQL statements or LDAP
>>> queries evaluated internally by the PIP.
>>> For example, an attribute called subject-employed-by-ip-owner that
>>> indicates the boolean result of an internal PIP query to evaluate
>>> whether the subject is an employee of the IP owner. I see a number
>>> of problems with an approach like this.
>>> (1) It assumes that the PIP has all the necessary information to
>>> query. Some attributes (like ip-owner) may only come from the PEP in
>>> the authorization request.
>>> It is only the context handler and PDP that are guaranteed to have
>>> the complete request context for evaluation.
>> Typically in an implementation a PIP can ask the context handler for
>> more "key values" which it would need, so this is not a problem in
>> practice given that the implementation is done right.
> Is there a standard somewhere that describes how a conformant PIP can
> query the context handler ? I haven't noticed one, either formal or
> defacto.
> More importantly,
> are there any interoperable implementations that can do this ? I'm not
> aware of any. The essence of your solution seems to be to ask
> implementors to do something proprietary, which isn't a very
> satisfying answer for a group that is supposed to be about enabling
> interoperable implementations.
>>> (2) It is necessary to define a new attribute and configure the PIP
>>> with a new
>>> SQL statement, LDAP query, or whatever, for each new expression the
>>> policy writer
>>> wants to use that is beyond the current capabilities for XACML to
>>> express.
>> That is correct. I don't see this as a huge problem.
> There is no XACML standards support for doing this sort of PIP
> configuration
> and coordination between PAP and PIP. I see that as a huge problem for
> interoperability.
>>> (3) It splits the policy evaluation between the PDP and the PIP. It
>>> is no longer
>>> sufficient to examine the XACML policies to understand the effect of
>>> access control
>>> policy. It is necessary to also examine the SQL statements, LDAP
>>> queries, etc. to
>>> understand what the complete authorization policy is. For
>>> interworking, it is also
>>> necessary to export the XACML policies from the PAP and the SQL
>>> statements, LDAP
>>> queries, etc. from the PIP.
>> Yes, this is the main drawback in my opinion. But it's something one
>> can live with.
> I'm not willing to live with it. Again there is no XACML standards
> support for
> doing all this stuff. If you were offering to create those standards
> it would be
> a different story, but it would be a lot more work than the extensions
> I was
> talking about. And I would be the one writing up those extensions anyway.
>>> If that isn't the approach you had in mind, then you need to
>>> describe what you
>>> are thinking. An example of how you would tackle a condition like
>>> "the subject is
>>> an employee of the IP owner" would be useful for comparison.
>> This is the approach I do have in mind.
>> The reason I prefer this is because the amount of "new stuff" we
>> would have to add to XACML to handle all
>> such cases of attributes of relations is a big deal.
> You overstate the amount of new stuff. The non-trivial example I gave
> had only
> three lines that weren't core XACML, and one of those was an end-tag.
> The iterator
> expressions are a generalization of the numerous bag functions that
> already
> exist. The attribute-designator is just an AttributeDesignator
> expressed as
> a function. They are modest changes that provide a big improvement in
> expressibility and solve the problems of the IPC profile, among other
> things.
> > We will basically end up re-implementing a SQL like
>> language within XACML, and I doubt what the value of that would be
>> since SQL implementation are ubiquitous
>> and can already do all this for us.
>> Adding something SQL like within XACML is going to be costly in terms
>> of TC effort, implementation effort
>> and customer learning curve for XACML products.
> There's already a big overlap between what SQL and XACML can express,
> they
> just do it differently. XACML is already way more expressive than an LDAP
> filter. It isn't necessary to reinvent SQL or LDAP filters to solve the
> problems of the IPC profile. Much of the reinventing has happened
> already.
> Adding a bit more to what's already there is enough.
> > And in the end, it won't do anything which cannot be done
>> today, with the exception of a more fully visible authorization logic
>> in the XACML policy.
> That in itself is a good thing since it's one of the claimed benefits
> of centralized
> authorization, but it also enables interoperable implementations. If
> that's not
> what the TC is about, then what is it for ?
> Regards,
> Steven
>> Best regards,
>> Erik
>>> Regards,
>>> Steven
>>>> Best regards,
>>>> Erik
>>>> On 2012-12-17 07:43, Steven Legg wrote:
>>>>> Hi Richard,
>>>>> On 30/11/2012 8:13 AM, Hill, Richard C wrote:
>>>>>> The topic of "attributes of relations" came up during our work on
>>>>>> the IPC profile that I would like to
>>>>>> bring
>>>>>> to the list for discussion.
>>>>>> For example, an intellectual property agreement (Copyright,
>>>>>> Patent, Proprietary, etc.) is essentially a
>>>>>> contract between parties (subjects) regarding the use of
>>>>>> resources. The "agreement" is a relationship
>>>>>> between subject and resource. The question of how to best model
>>>>>> relationships like this with XACML
>>>>>> attributes is what I would like bring up for discussion. So far
>>>>>> two approaches to this problem have been
>>>>>> proposed:
>>>>>> 1.) Creating new attribute categories that would represent the
>>>>>> relationships. Below is an excerpt from Hal
>>>>>> regarding this approach.
>>>>>> 2.) Determine the relationship at the PIP. This is one approach
>>>>>> that IPC profile suggests regarding the
>>>>>> use
>>>>>> of the Agreement-Id, Valid-Agreement-Exists and
>>>>>> Number-Of-Valid-Agreements attributes. Below is an excerpt
>>>>>> from Erik on some of his thoughts on this topic.
>>>>> I think Hal is on the right track but hasn't taken it far enough.
>>>>> I've encountered use cases where I need to reference attributes
>>>>> that are not
>>>>> part of the subject, but rather are attributes of some
>>>>> entity/object that is
>>>>> related to subject. For example, attributes of the organization
>>>>> that employs
>>>>> the subject, or attributes of another person, being the
>>>>> parent/guardian of the
>>>>> subject. The IPC and EC-US profiles have other examples of a need
>>>>> to reference
>>>>> attributes of things related to the subject or resource, but not
>>>>> really part
>>>>> of the subject or resource.
>>>>> The IPC and EC-US profiles try to shoehorn these attributes of
>>>>> related objects
>>>>> into the subject and resource categories by "flattening", but this
>>>>> is woefully
>>>>> inadequate when the relationships are one-to-many or many-to-many.
>>>>> Consider this simple example as an illustration. I want to
>>>>> indicate that the
>>>>> subject is an employee of Ajax Inc, a commercial organization,
>>>>> which is a
>>>>> customer of Widget Inc., a non-profit organization and also the IP
>>>>> owner.
>>>>> The subject is also a contractor to Widget Inc. The IPC profile
>>>>> would have me
>>>>> create a request context something like this (from here on I've
>>>>> shortened all
>>>>> the URIs to just the last part and removed the IncludeInResult XML
>>>>> attributes
>>>>> in the interest of readability):
>>>>> <Attributes Category="access-subject">
>>>>>   <Attribute AttributeId="subject-to-organization-relationship">
>>>>>     <AttributeValue DataType="anyURI">employee</AttributeValue>
>>>>>     <AttributeValue DataType="anyURI">contractor</AttributeValue>
>>>>>   </Attribute>
>>>>>   <Attribute AttributeId="organization">
>>>>>     <AttributeValue DataType="string">Ajax Inc.</AttributeValue>
>>>>>     <AttributeValue DataType="string">Widget Inc.</AttributeValue>
>>>>>   </Attribute>
>>>>>   <Attribute AttributeId="organization-type">
>>>>>     <AttributeValue DataType="anyURI">commercial</AttributeValue>
>>>>>     <AttributeValue DataType="anyURI">non-profit</AttributeValue>
>>>>>   </Attribute>
>>>>>   <Attribute AttributeId="business-context">
>>>>>     <AttributeValue DataType="anyURI">customer</AttributeValue>
>>>>>   </Attribute>
>>>>>   <!-- Other subject attributes here. -->
>>>>> </Attributes>
>>>>> <Attributes Category="resource">
>>>>>   <Attribute AttributeId="ip-owner">
>>>>>     <AttributeValue DataType="string">Widget Inc.</AttributeValue>
>>>>>   </Attribute>
>>>>>   <!-- Other attributes of the resource. -->
>>>>> </Attributes>
>>>>> The "flattening" process makes the request context ambiguous and
>>>>> leaves policy
>>>>> evaluation open to false-positive and false-negative results.
>>>>> Which organization
>>>>> is the subject an employee of ? Is it both ? Which organization is
>>>>> commercial
>>>>> and which is non-profit ? There's no way to tell from the request
>>>>> context.
>>>>> The real world allows objects of many kinds that can be related to
>>>>> each other
>>>>> in many ways. To capture that reality, XACML needs the ability to
>>>>> represent a
>>>>> request context that is a graph of objects, rather than a small
>>>>> list of
>>>>> predefined categories. If I reinterpret a category as an object
>>>>> (i.e., a list
>>>>> of attributes) and use attribute values of the anyURI data-type as
>>>>> references
>>>>> between objects, then I can turn the request context into a graph
>>>>> without
>>>>> changing the syntax at all. Having a predetermined category URI
>>>>> isn't adequate
>>>>> when there is a need to represent multiple instances of the same
>>>>> kind of object,
>>>>> as Erik points out. The answer is to decouple the kind of a object
>>>>> from the
>>>>> category URI by regarding the category URI as simply a unique
>>>>> identifier for
>>>>> a distinct object. These URIs could be anything, e.g., UUIDs, LDAP
>>>>> URLs,
>>>>> OID URNs, or whatever. The predefined category URIs become well
>>>>> known aliases
>>>>> for singling out the particular objects that are significant to
>>>>> the access
>>>>> attempt, e.g., the subject and resource. These objects are the
>>>>> entry points
>>>>> into the graph.
>>>>> If I break out the different entities and relationships into separate
>>>>> <Attributes> elements and use anyURI values to link them, then I
>>>>> get a
>>>>> request context that looks like this:
>>>>> <Attributes Category="access-subject">
>>>>>   <Attribute AttributeId="relationship-ref">
>>>>>     <AttributeValue DataType="anyURI">relationship-1</AttributeValue>
>>>>>     <AttributeValue DataType="anyURI">relationship-2</AttributeValue>
>>>>>   </Attribute>
>>>>>   <!-- Other subject attributes. -->
>>>>> </Attributes>
>>>>> <Attributes Category="relationship-1">
>>>>>   <Attribute AttributeId="subject-to-organization-relationship">
>>>>>     <AttributeValue DataType="anyURI">employee</AttributeValue>
>>>>>   </Attribute>
>>>>>   <Attribute AttributeId="organization-ref">
>>>>>     <AttributeValue DataType="anyURI">organization-1</AttributeValue>
>>>>>   </Attribute>
>>>>> </Attributes>
>>>>> <Attributes Category="relationship-2">
>>>>>   <Attribute AttributeId="subject-to-organization-relationship">
>>>>>     <AttributeValue DataType="anyURI">contractor</AttributeValue>
>>>>>   </Attribute>
>>>>>   <Attribute AttributeId="organization-ref">
>>>>>     <AttributeValue DataType="anyURI">organization-2</AttributeValue>
>>>>>   </Attribute>
>>>>> </Attributes>
>>>>> <Attributes Category="organization-1">
>>>>>   <Attribute AttributeId="organization"
>>>>>     <AttributeValue DataType="string">Ajax Inc.</AttributeValue>
>>>>>   </Attribute>
>>>>>   <Attribute AttributeId="organization-type">
>>>>>     <AttributeValue DataType="anyURI">commercial</AttributeValue>
>>>>>   </Attribute>
>>>>>   <Attribute AttributeId="business-context-ref">
>>>>>     <AttributeValue
>>>>> DataType="anyURI">business-context-1</AttributeValue>
>>>>>   </Attribute>
>>>>>   <!-- Other attributes of organization "Ajax Inc." here. -->
>>>>> </Attributes>
>>>>> <Attributes Category="business-context-1">
>>>>>   <Attribute AttributeId="business-context">
>>>>>     <AttributeValue DataType="anyURI">customer</AttributeValue>
>>>>>   </Attribute>
>>>>>   <Attribute AttributeId="organization-ref">
>>>>>     <AttributeValue DataType="anyURI">organization-2</AttributeValue>
>>>>>   </Attribute>
>>>>> </Attributes>
>>>>> <Attributes Category="organization-2">
>>>>>   <Attribute AttributeId="organization"
>>>>>     <AttributeValue DataType="string">Widget Inc.</AttributeValue>
>>>>>   </Attribute>
>>>>>   <!-- Other attributes of organization "Widget Inc." here. -->
>>>>> </Attributes>
>>>>> <Attributes Category="resource">
>>>>>   <Attribute AttributeId="ip-owner">
>>>>>     <AttributeValue DataType="anyURI">organization-2</AttributeValue>
>>>>>   </Attribute>
>>>>>   <!-- Other attributes of the resource. -->
>>>>> </Attributes>
>>>>> The affiliation of the subject to an organization is represented
>>>>> by an object
>>>>> (<Attributes> element) containing the
>>>>> subject-to-organization-relationship
>>>>> attribute. The relationship of one organization to another is
>>>>> represented by
>>>>> an object containing the business-context attribute. Each of the
>>>>> organizations
>>>>> is represented by an object containing the organization attribute.
>>>>> Note that
>>>>> relationship-1, relationship-2, organization-1, organization-2 and
>>>>> business-context-1 are not predefined URIs. I'm using them as
>>>>> placeholders
>>>>> for UUIDS, or something similar, that uniquely identify each object.
>>>>> With the above request context I am able to faithfully represent
>>>>> the situation
>>>>> I originally expressed in English. I don't expect that the PEP
>>>>> would actually
>>>>> provide a request context like this. More likely, the context
>>>>> handler would
>>>>> construct the request context on demand by querying a PIP, given a
>>>>> bare-bones
>>>>> subject and resource provided by the PEP as a starting point.
>>>>> The next thing I need to address is how a graph-like request
>>>>> context can be
>>>>> evaluated by policies.
>>>>> The first thing to note is that attribute designators use
>>>>> predetermined URIs
>>>>> for the category, but most of the graph objects have URIs that
>>>>> won't be
>>>>> known at the time a policy is written, and may vary over time. To
>>>>> overcome
>>>>> that I need an attribute designator in the form of a function so
>>>>> that I can
>>>>> feed into it the URI values fetched by other attribute designators.
>>>>> So an attribute designator like this:
>>>>>     <AttributeDesignator
>>>>>       Category="access-subject"
>>>>>       AttributeId="relationship-ref"
>>>>>       DataType="anyURI"
>>>>>       MustBePresent="false"/>
>>>>> is equivalent to an attribute-designator function:
>>>>>     <Apply FunctionId="attribute-designator">
>>>>>       <AttributeValue
>>>>> DataType="anyURI">access-subject</AttributeValue>
>>>>>       <AttributeValue
>>>>> DataType="anyURI">relationship-ref</AttributeValue>
>>>>>       <AttributeValue DataType="anyURI">anyURI</AttributeValue>
>>>>>       <AttributeValue DataType="boolean">false</AttributeValue>
>>>>>     </Apply>
>>>>> Each of the arguments, especially the first one, is able to be an
>>>>> arbitrary
>>>>> expression instead of a constant.
>>>>> The attribute-designator function isn't enough by itself. To do
>>>>> really
>>>>> interesting things with the graph I find I also need to invoke the
>>>>> iterator
>>>>> expressions I described on the comment list some time ago:
>>>>> https://lists.oasis-open.org/archives/xacml-comment/201101/msg00007.html
>>>>> Armed with the attribute designator function and the ForAny
>>>>> expression I
>>>>> can apply conditions to any part of the graph. For example, if I
>>>>> want to
>>>>> test whether the subject is an employee of the IP owner I could
>>>>> use this
>>>>> expression:
>>>>> <ForAny VariableId="$a">
>>>>>   <!-- $a is bound to each relationship-ref URI in turn -->
>>>>>   <AttributeDesignator
>>>>>     Category="access-subject"
>>>>>     AttributeId="relationship-ref"
>>>>>     DataType="anyURI"
>>>>>     MustBePresent="false"/>
>>>>>   <Apply FunctionId="and">
>>>>>     <!-- Return true if and only if the
>>>>> subject-to-organization-relationship of
>>>>>          the relationship object referenced by $a contains the
>>>>> value "employee". -->
>>>>>     <Apply FunctionId="anyURI-is-in">
>>>>>       <AttributeValue DataType="anyURI">employee</AttributeValue>
>>>>>       <Apply FunctionId="attribute-designator">
>>>>>         <VariableReference VariableId="$a"/>
>>>>>         <AttributeValue
>>>>> DataType="anyURI">subject-to-organization-relationship</AttributeValue>
>>>>>         <AttributeValue DataType="anyURI">anyURI</AttributeValue>
>>>>>         <AttributeValue DataType="boolean">false</AttributeValue>
>>>>>       </Apply>
>>>>>     </Apply>
>>>>>     <!-- Return true if and only if the organization referenced by
>>>>> the relationship
>>>>>          object referenced by $a is the IP owner. -->
>>>>>     <Apply FunctionId="anyURI-at-least-one-member-of">
>>>>>       <Apply FunctionId="attribute-designator">
>>>>>         <VariableReference VariableId="$a"/>
>>>>>         <AttributeValue
>>>>> DataType="anyURI">organization-ref</AttributeValue>
>>>>>         <AttributeValue DataType="anyURI">anyURI</AttributeValue>
>>>>>         <AttributeValue DataType="boolean">false</AttributeValue>
>>>>>       </Apply>
>>>>>       <AttributeDesignator
>>>>>         Category="resource"
>>>>>         AttributeId="ip-owner"
>>>>>         DataType="anyURI"
>>>>>         MustBePresent="false"/>
>>>>>     </Apply>
>>>>>   </Apply>
>>>>> </ForAny>
>>>>> For the record, the answer is false for the graph request context
>>>>> I provided
>>>>> above. The current profile with "flattening" is incapable of such
>>>>> precision.
>>>>> I would expect to write up the graph-like request context, the
>>>>> attribute
>>>>> designator function and iterator expressions as a separate profile
>>>>> since they
>>>>> are generally useful beyond just the IPC profile.
>>>>> Regards,
>>>>> Steven
>>>>>> - Richard
>>>>>> --------------------------------------------------------------------------------
>>>>>> On 2012-10-10 04:04, Hal Lockhart wrote (excerpt):
>>>>>> --------------------------------------------------------------------------------
>>>>>> ...I have been aware for some time that the Categories of
>>>>>> Subject, Resource, Action & Environment are
>>>>>> insufficient as policies become more complex. The first use case
>>>>>> I encountered of this kind was when
>>>>>> trying
>>>>>> to label certain operations as "Administrative". There is a need
>>>>>> to associate the attribute not with the
>>>>>> Resource or Action, but with the combination. For example, all
>>>>>> operations on Usage Reports might be
>>>>>> Administrative, whereas only creating an Account might be
>>>>>> Administrative, other Account operations would
>>>>>> not be.
>>>>>> Some Access Control Models consider Action to be a part of
>>>>>> Resource, on the theory that to, for example,
>>>>>> write a file and to write a database record are not really the
>>>>>> same in important ways. I think the XACML
>>>>>> treatment of Action as a first class Category has certain
>>>>>> advantages, for example in the case where you
>>>>>> want
>>>>>> to write a policy about ALL reads or writes.
>>>>>> I have opposed using selectors to solve this problem for several
>>>>>> reasons. First, it tends to hide what is
>>>>>> intended in a complicated expression. Second, I think it is
>>>>>> undesirable for references to attributes be
>>>>>> dependent on the means used to obtain them. The foo attribute
>>>>>> should be the foo attribute whether it came
>>>>>> from LDAP, SAML or SQL. Also it makes the system fragile. If the
>>>>>> attribute location changes, the policies
>>>>>> have to change. I objected to Jan Hermann's proposal that we have
>>>>>> Input Message and Output Message
>>>>>> Categories for the same reason. Finally, I consider Selectors to
>>>>>> be a mechanism to access attributes in
>>>>>> the
>>>>>> request context when a suitable designator has not (yet) been
>>>>>> defined. Using a selector to access a
>>>>>> repository seems like a kludge to me.
>>>>>> My preferred alternative in such cases is to define a new
>>>>>> category type, say, Resource-Action. A possible
>>>>>> objection is that we could end up with an explosion of
>>>>>> Categories, but while this could be true, I
>>>>>> think it
>>>>>> comes from the real world nature of the problem and thus will be
>>>>>> a feature of any solution. The selector
>>>>>> will be different for every attribute and repository combination,
>>>>>> possibly an even larger set.
>>>>>> Notwithstanding all that, I am not sure that is the problem in
>>>>>> your case below. I don't think the
>>>>>> patent, or
>>>>>> copyright or license are attributes of the relationship, they are
>>>>>> attributes of the Resource
>>>>>> (document), The
>>>>>> relationship is what you are trying to capture in the policy. For
>>>>>> example, somebody has licensed Boeing to
>>>>>> use this document. The policy says that since John Tolbert works
>>>>>> for Boeing, he can use the document.
>>>>>> I think the problem in this case is that your attributes are not
>>>>>> flat scalars, but contain multiple
>>>>>> fields.
>>>>>> I am not prepared to propose a data model, but it seems to me you
>>>>>> problem is that the copyright attribute
>>>>>> needs to be qualified by country and perhaps other fields. XACML
>>>>>> requires new functions to deal with new
>>>>>> attribute types as a whole, e.g. GeoXACML, but the existing
>>>>>> functions can deal with one field at a time
>>>>>> just
>>>>>> fine.
>>>>>> Hal
>>>>>> --------------------------------------------------------------------------------
>>>>>> On 2012-10-09, 10:50 PM, Erik Rissanen wrote (excerpt):
>>>>>> --------------------------------------------------------------------------------
>>>>>> ...There are different ways to deal with this issue. Defining a
>>>>>> new category like you suggest Hal will not
>>>>>> solve the problem because even if you have a new category, you
>>>>>> cannot separate multiple instances of the
>>>>>> same category, thus you cannot represent multiple relations this
>>>>>> way.
>>>>>> My recommendation is to resolve the relations in a PIP. It puts
>>>>>> some of the "logic" outside the XACML
>>>>>> policy
>>>>>> but it is the most pragmatic approach, since it does not need any
>>>>>> extensions to XACML and leads to simple
>>>>>> XACML policies.
>>>>>> Using complex data types, either in the form of xml <Content> and
>>>>>> selectors, tuples represented as
>>>>>> strings,
>>>>>> or XACML data type extensions also work, but mean unwieldy
>>>>>> expressions in policies or XACML extensions
>>>>>> which
>>>>>> need to be implemented in code in the PDP.
>>>>>> One idea I have been toying with in my mind for a long time has
>>>>>> been to define a sort of generic tuple
>>>>>> data
>>>>>> type for XACML, but I have not been able to design a nice and
>>>>>> clean set of operators on it, so I have not
>>>>>> posted anything on the list. There is a suggestion like this on
>>>>>> the XACML comments list, btw.
>>>>>> One could extend on this tuple idea, and when one thinks about
>>>>>> the various operations which would be
>>>>>> needed,
>>>>>> one ends up re-inventing SQL, so I figured there is little
>>>>>> practical value for XACML to do so. This can be
>>>>>> done on the database side in a PIP. I guess there would be some
>>>>>> value in terms of explicit
>>>>>> visibility, but I am not convinced, so I never pursued this
>>>>>> thread of thought on the TC list.
>>>>>> Best regards,
>>>>>> Erik
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: xacml-unsubscribe@lists.oasis-open.org
>>>>> For additional commands, e-mail: xacml-help@lists.oasis-open.org
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: xacml-unsubscribe@lists.oasis-open.org
>>>> For additional commands, e-mail: xacml-help@lists.oasis-open.org

To unsubscribe, e-mail: xacml-unsubscribe@lists.oasis-open.org
For additional commands, e-mail: xacml-help@lists.oasis-open.org

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