Next in thread →
Next in month →
Re: [xacml] Re: How to get attributes from other categories
Hi Steven,
I have read your reply, and I think I now see the big picture of
what
you are trying to do. The most important email appears to be:
https://lists.oasis-open.org/archives/xacml/201212/msg00041.html
which describes your overall approach, and has some key definitions,
such as the attribute-designator function and includes a ref to
another email you sent to xacml-comment:
https://lists.oasis-open.org/archives/xacml-comment/201101/msg00007.html
which describes the main constructs of your proposal, such as the
<ForAny VariableId="arg"> construct that provides the iterator
and variable over which the iteration is performed.
Basically, I agree w your analysis of the overall problem space and
your use of Category for entities and relationships in the
RequestContext,
and your use of the category identifiers in order to represent
associations between entities.
To be honest, I have only reviewed the details above briefly,
particularly
in the context of the examples in your reply, which I assume came
out of your email threads w Erik back in January this year:
https://lists.oasis-open.org/archives/xacml/201301/msg00018.html
https://lists.oasis-open.org/archives/xacml/201301/msg00035.html
With the above references in mind, what I plan to do next is to
consider whether the bag-function proposal I made in the previous
email can be used to address this situation, w the objective being
to get the <ForAny> out of the policy and into the bag
function
arena. I am not sure yet whether that can be done effectively,
but I will need to try it and find one way of the other.
The motive is to try to keep the policy language more or
less "declarative" in its current form and to use the functional
programming methods to enable the features you have
proposed.
I understand your concern about adding new FunctionId's and
the interoperability issues that could potentially create, however,
I think if we published the solutions in an opensource repository
than users could keep their deployments current on an
as-needed basis.
As for the number of "proposals" I have "offered", I see this
more as an iterative process, where I have been trying to
understand what the requirements are that you have
proposed. In that process I have progressively made
suggestions to address what I saw as the reqts, and
you have progressively come back w more detailed
use cases that appeared in earlier emails.
I think my original premise has been validated that the
essential problem being solved is addressing attributes
in other categories, however, what I have come to
understand is that what is also needed is a framework
for processing these attributes, which appears to
me now to fundamentally be the bag construct and
how to process it.
Bottom line: I think the reqts are now well understood
and I am regarding your soln as an abstract representation
of those reqts and the objective now from my perspective
is how "implement" that abstraction in the concrete
framework that xacml 3.0 provides, which I think
boils down to a question of whether the core language
needs to be modified or can those modifications be
exposed more benignly thru the bag function constructs.
Thanks,
Rich
On 8/13/2013 8:52 PM, Steven Legg
wrote:
Hi Rich,
On 11/08/2013 5:19 PM, rich levinson wrote:
Hi Steven,
Again, I will reply to your detailed questions later, however,
I'd like
to keep the focus on addressing what I consider to be the real
issue
here which is that I would prefer not to introduce loops and
variables
to the core language, at least not in the form you have
proposed.
Your point about the analogy to the bag functions is well taken,
and I agree the bag functions have implicit iterators and loops,
but from my perspective, that is the way XACML, early on, chose
to address this problem (long before I was associated w the TC).
In my prev email I considered trying to do something w bag fcns
to addr the issue, but it was not immediately obvious to me
what the strategy should be.
Your analogy was very helpful in this regard, where you
demonstrated
the equivalence of the <ForAny> construct to the implicit
operation
of the bag functions that effectively under the covers need to
create a loop of some sort and iterate thru a variable that uses
one value from the bag for each time thru the loop.
So, what I am thinking is maybe the reverse logic can show us
some possiblities: i.e. take the ForAny construct that you
have proposed and consider what it might look like as a
bag function.
What I have empirically come up with is the following:
<Apply FunctionId="all-of-any-category">
<Function FunctionId="boolean-and">
<AttributeDesignator // bag of
categoryId's
Category="access-subject"
AttributeId="organization"
DataType="anyURI"
MustBePresent="false"/>
<Apply FunctionId="string-bag"> // bag of
attrId's
<AttributeValue
DataType="string">organization-us</AttributeValue>
<AttributeValue
DataType="string">organization-np</AttributeValue>
</Apply>
<AttributeValue
DataType="boolean">true</AttributeValue>
</Apply>
The above is basically a new bag function that takes 4
arguments:
* a FunctionId to be applied to two operands
* a bag of categoryIds
* a bag of attributeIds
* a bag of values, in this case just one value: true
The "new" aspect to this function would be: using the pair of
arguments (bag of categoryIds, bag of attributeIds) in the
following manner:
for each categoryId
return a bag of AttributeDesignators where there is
one designator for each AttributeId such that the
designator addresses the Attribute in the specific
category
therefore we'd end up w a nested loop w the outer
loop being category and the inner loop being the
attr-id's within the category.
By my count this is your fourth proposal. Are the other ones
still on the table ?
Because the addressing has changed in 3.0, where we now
have a general Category variable (the xml Category attribute
in the designators and selectors) from the situation in 2.0,
where
the Category was essentially fixed by the name of the
selector or designator element (i.e. the prefixes, Subject,
Action,...)
that has kind of left us with some loose ends such as the
bag functions that don't really have any way to handle
the notion of collection of collections, which is essentially
what the pair: Category,AttributeId gives us. i.e. a policy
element must now know 2 things to locate an attribute
in the request, the collection it is in and the attributeId
within the collection, whereas, before, because of the
constructs,
all that was needed was the AttributeId.
So, imo, it might be worth generalizing some sort of construct
that can be used w the bag functions such as what I have
suggested above, but maybe presented in a more simplified
manner if one is available.
Bottom line: the motivation for this proposal is again, to try
to avoid introducing looping and iteration constructs to the
policy language. Imo, the users of the language are not
a bunch of programmers wishing they could just write
the policy in Java, but more configuration and deployment
people who would like to add a line or remove a line
from a text configuration file in order to change policy.
Right now it is fairly straight forward to put together a
scripting equivalent to xacml which has this line at a time
flavor to it and gets rid of the extraneous xml constructs,
w a compression ratio of something like 5:1 i.e. 5 xacml
lines can generally be compressed to about 1 script line.
Like ForAny($org, some-bag, some-_expression_-using-$org) ?
The more verbose form would be:
there exists $org in some-bag such that some-_expression_-using-$org
W the proposal above, a new bag construct could be
introduced, which would handle a common function
of a double iterator w outer loop category, and
inner loop attrId, which wouldn't change the core spec
at all, but simply add a new bag function or possibly
a few new bag functions. Adding functions is considered
fair game for xacml, preferably w some profile defined
so that people know how to use the fcns.
Let me know if this approach sounds at all promising.
It would take much more than one new bag function to provide
reasonable
coverage. Your all-of-any-category function covers just one simple
pattern amongst a wide variety of useful patterns. Here are a
couple of
examples that came up in the "Attributes of Relations" thread.
Think
about the bag functions you would need to define to support these
kinds
of expressions, and then think about all the reasonable
possibilities
between these extreme cases and all-of-any-category.
<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>
<!-- Return true if this
subject-to-organization-relationship,
i.e., $a, has the latest start-date. -->
<ForAll VariableId="$b">
<!-- $b is bound to each relationship-ref URI in turn
-->
<AttributeDesignator
Category="access-subject"
AttributeId="relationship-ref"
DataType="anyURI"
MustBePresent="false"/>
<Apply FunctionId="any-of-all>
<Function
FunctionId="date-greater-than-or-equal"/>
<Apply FunctionId="attribute-designator">
<VariableReference VariableId="$a"/>
<AttributeValue
DataType="anyURI">start-date</AttributeValue>
<AttributeValue
DataType="anyURI">date</AttributeValue>
<AttributeValue
DataType="boolean">false</AttributeValue>
</Apply>
<Apply FunctionId="attribute-designator">
<VariableReference VariableId="$b"/>
<AttributeValue
DataType="anyURI">start-date</AttributeValue>
<AttributeValue
DataType="anyURI">date</AttributeValue>
<AttributeValue
DataType="boolean">false</AttributeValue>
</Apply>
</Apply>
</ForAll>
</Apply>
</ForAny>
<ForAny VariableId="$contract">
<AttributeDesignator
Category="access-subject"
AttributeId="contract"
DataType="anyURI"
MustBePresent="false"/>
<Apply FunctionId="and">
<Apply FunctionId="string-is-in">
<Apply FunctionId="string-one-and-only">
<AttributeDesignator
Category="access-subject"
AttributeId="location"
DataType="string"
MustBePresent="false"/>
</Apply>
<Apply FunctionId="attribute-designator">
<VariableReference VariableId="$contract"/>
<AttributeValue
DataType="anyURI">allowed-location</AttributeValue>
<AttributeValue
DataType="anyURI">string</AttributeValue>
<AttributeValue
DataType="boolean">false</AttributeValue>
</Apply>
</Apply>
<Apply FunctionId="anyURI-is-in">
<Apply FunctionId="anyURI-one-and-only">
<AttributeDesignator
Category="resource"
AttributeId="resource-id"
DataType="anyURI"
MustBePresent="false"/>
</Apply>
<Apply FunctionId="attribute-designator">
<VariableReference VariableId="$contract"/>
<AttributeValue
DataType="anyURI">resource-id</AttributeValue>
<AttributeValue
DataType="anyURI">anyURI</AttributeValue>
<AttributeValue
DataType="boolean">false</AttributeValue>
</Apply>
</Apply>
<Apply FunctionId="integer-less-than">
<Apply FunctionId="string-bag-size">
<Apply FunctionId="attribute-designator">
<VariableReference VariableId="$contract"/>
<AttributeValue
DataType="anyURI">log_entry</AttributeValue>
<AttributeValue
DataType="anyURI">string</AttributeValue>
<AttributeValue
DataType="boolean">false</AttributeValue>
</Apply>
</Apply>
<Apply FunctionId="integer-one-and-only">
<Apply FunctionId="attribute-designator">
<VariableReference VariableId="$contract"/>
<AttributeValue
DataType="anyURI">use_limit</AttributeValue>
<AttributeValue
DataType="anyURI">integer</AttributeValue>
<AttributeValue
DataType="boolean">false</AttributeValue>
</Apply>
</Apply>
</Apply>
</Apply>
</ForAny>
Allowing for variations such as attributes of different data
types, boolean
expressions other than flat conjunction and disjunction,
normalization of
attribute values for comparison, associations of associations,
comparisons
between entity attributes, comparisons between attributes of
different
associated entities, and so on, makes for a large set of patterns
and thus
a large number of specialized bag functions.
Now you could say that we only specify the few most important
patterns, but
users will inevitably need to go beyond that, so we will be locked
into an
endless cycle of function creep. Users will be left waiting for
the TC to
define the functions they need and for their vendors to implement
those
functions, if it happens at all. Interoperability between
implementations
will also suffer as they won't all be up-to-date with the latest
list of
bag functions.
After some years a reasonable collection of specialized bag
functions may
result, but they will always be the poor second cousin to what the
iterator
expressions can achieve in one stroke. The iterator expressions
achieve
more with greater economy of specification, implementation and
user
comprehension.
Regards,
Steven
Thanks,
Rich
a specific category and attribute
On 8/9/2013 2:35 AM, Steven Legg wrote:
Hi Rich,
On 8/08/2013 7:09 PM, rich levinson wrote:
Hi Steven,
I am going to try to reset the discussion a bit, because I
think that
w the discussion we have had the priority of concerns has
evolved.
Therefore, I will re-present the use case, drawn, I believe,
from your
description a couple emails back.
That is followed by a specific example request, which,
again,
I think we agree on the org cats, but I am proposing a new
middle
ground subject-access, that contains an attribute containing
a list of cats that provides some explicit binding between
the
subject-access and the associated organizations.
Finally, there is an example policy, again, derived from
some of
your suggestions in earlier emails, which effectively goes
thru
each enumerated org category looking for one meets the
two condition reqt of being both np and us.
That is followed by some comments.
I had first started by responding to the individual comments
you
made last time, and can provide those if you are interested,
however,
I think if we can re-baseline the issue then core issues
that are being
discussed will be easier to identify.
Here is a rough cut of a new proposal to be considered as an
alternative your proposal, which is in the prev emails.
The use case is a request that will be processed
by a policy that will ask the question:
"Is the user associated with an organization that
is both non-profit (np) and based in US (us)?"
It has been agreed that the request can contain
a uniquely named category for each organization
that the user is associated with, and in this
case we are naming the categories:
organization-1
organization-2
...
The maximum number of such categories is a subject
of discussion, however, the xacml requirement
appears to be that to differentiate the
organizations within the request, each must
have a unique category name.
The example request contains two organizations,
each in its own category. In addition, the
subject has its usual subject-access category.
Additional categories, such as resource and
env are suppressed as being extraneous wrt
relevance to the issued being considered.
The following is a simple minimal request that
contains a subject-access containing one
attr that has a list of orgs the user
is associated w, represented by their
category names as they appear elsewhere
in the request.
<Request>
<Attributes Category="subject-access">
<Attribute
AttributeId="organization-categories">
organization-1
organization-2
</Attribute>
</Attributes>
<Attributes Category="organization-1">
<Attribute AttributeId="organization-np">
<AttributeValue DataType="boolean"
>true</AttributeValue>
</Attribute>
</Attributes>
<Attributes Category="organization-2">
<Attribute AttributeId="organization-np">
<AttributeValue DataType="boolean"
>true</AttributeValue>
</Attribute>
<Attribute AttributeId="organization-us">
<AttributeValue DataType="boolean"
>true</AttributeValue>
</Attribute>
</Attributes>
</Request>
In this case the user's associations are represented
by a single multi-valued attribute, that contains
a list of the orgs the user belongs to.
The policy condition might be written as follows
(which is slightly adapted from Steven's comment
in prev email as to how to simplify the proposal
I had prev made): The logic of the following is basically:
// is org 1 OR org 2 both np and us?
// is org 1 in list of cats AND buth np and us?
// is org 1 in subject list of cats?
// is org 1 both np and us?
// is org 1 np?
// is org 1 us?
// is org 2 in list of cats AND buth np and us?
// is org 2 in subject list of cats?
// is org 2 both np and us?
// is org 2 np?
// is org 2 us?
<Apply FunctionId="or"> // is org 1
OR org 2 both np and us?
<Apply FunctionId="and"> // is org 1
in list of cats AND buth np and us?
<Apply FunctionId="string-is-in" // is org 1
in subject list of cats?
<AttributeValue
DataType="string">organization-1</AttributeValue>
<AttributeDesignator
Category="subject-access"
AttributeId="organization-categories"
DataType="string"
MustBePresent="false"/>
</Apply>
<Apply FunctionId="and"> // is org
1 both np and us?
<Apply FunctionId="boolean-is-in"> // is
org 1 np?
<AttributeValue
DataType="boolean">true</AttributeValue>
<AttributeDesignator
Category="organization-1"
AttributeId="organization-np"
DataType="boolean"
MustBePresent="false"/>
</Apply>
<Apply FunctionId="boolean-is-in"> // is
org 1 us?
<AttributeValue
DataType="boolean">true</AttributeValue>
<AttributeDesignator
Category="organization-1"
AttributeId="organization-us"
DataType="boolean"
MustBePresent="false"/>
</Apply>
</Apply>
</Apply>
<Apply FunctionId="and"> // is org 2
in list of cats AND buth np and us?
<Apply FunctionId="string-is-in" // is org 2
in subject list of cats?
<AttributeValue
DataType="string">organization-2</AttributeValue>
<AttributeDesignator
Category="subject-access"
AttributeId="organization-categories"
DataType="string"
MustBePresent="false"/>
</Apply>
<Apply FunctionId="and"> // is org
2 both np and us?
<Apply FunctionId="boolean-is-in"> // is
org 2 np?
<AttributeValue
DataType="boolean">true</AttributeValue>
<AttributeDesignator
Category="organization-2"
AttributeId="organization-np"
DataType="boolean"
MustBePresent="false"/>
</Apply>
<Apply FunctionId="boolean-is-in"> // is
org 2 us?
<AttributeValue
DataType="boolean">true</AttributeValue>
<AttributeDesignator
Category="organization-2"
AttributeId="organization-us"
DataType="boolean"
MustBePresent="false"/>
</Apply>
</Apply>
</Apply>
</Apply>
In the above policy, the fact that the list of org
categories
is in the subject-access category serves to loosely, but
explicitly bind the attrs in those cats to the subject.
There are 2 alternatives to this that also seem to make
a degress of sense:
- there can be no list of cats in subject-access,
in which case the binding is implicit
- the subject-access could also include a list
of specific attributes that it points to
in the org categories
The 3rd alternative is what is given above, where the
explicit binding is at the category level, so the
3 possible structures are:
- implicit binding of subject-access to org-cats in
request
- explicit cat binding as shown above
I'm not clear on what the distinction between the two above
cases actually is.
The explicit category binding only appears necessary if the
category identifiers
are permanent identifiers for organization entities. For
example, there may be
10 organizations with fixed identifiers "organization-1",
"organization-2", ...
"organization-10". Supposing that an access-subject can be
associated with up to
two organizations, the explicit organization categories for
one access-subject
could be "organization-1" and "organization-2", but for
another access-subject
they might be "organization-3" and "organization-7".
I think the implicit binding is what I had in mind. If an
access-subject can be
associated with up to two organizations, then the URIs
"organization-1" and
"organization-2" are defined as aliases for the associated
organizations and
the bindings are valid only for the duration of the request
context. Different
requests for different access-subjects will possibly bind
these URIs to different
real-world organizations, i.e., the ones associated with that
access-subject.
An "organization-categories" attribute isn't required in the
access-subject
because we know they will be "organization-1" and
"organization-2", if categories
with those identifers exist at all on the request context.
If I've got the distinction right, then the explicit category
binding has even
worse scaling characteristics than the implicit binding. If
there are ten
organizations and an access-subject can be associated with up
to two of them,
then the "or" _expression_ for explicit category binding would
need to have ten
"and" terms, while the "or" _expression_ for implicit binding
would only need
two "and" terms. The expressions must grow to accommodate the
maximum number
of organization associations in the implicit case, but must
grow to
accommodate the maximum number of organizations in the
explicit case. The former
will usually be much smaller than the latter, and never
larger. The expressions
must also be rewritten in the explicit case when the number of
organizations
increases.
- explicit attr by attr binding
from subj to specific org attrs
It is the 3rd case that was the focal point of the prev
emails, however, given the above 3 choices the particular
points in those emails may be too detailed for highest
priority aspects of this issue.
Using this as a starting point it might be easier now to
compare the two solutions which I would now characterize as:
1. dynamic category processing using dynamic variables
and iteration loops
2. static category processing using enumerated list of
explicit category identifiers.
imo, the main issue is whether "2" can be set up to be
"enough", which can be done relatively few tweaks or
possibly using xacml, as is, as might be the case
for implicit or cat binding above. Attr binding
would require a few "tweaks",
or whether "1" is reqlly what's required, which really
changes the xacml policy language quite significantly
w loops and variables.
The difference is not as great as you think. XACML already has
many functions
that loop; the variables are just hidden in the function
definitions. Take the
boolean-is-in function as just one example. An _expression_ like
the following:
<Apply FunctionId="boolean-is-in">
<AttributeValue
DataType="boolean">true</AttributeValue>
<AttributeDesignator
Category="organization-2"
AttributeId="organization-us"
DataType="boolean"
MustBePresent="false"/>
</Apply>
has an equivalent form using a ForAny _expression_:
<ForAny VariableId="$value">
<AttributeDesignator
Category="organization-2"
AttributeId="organization-us"
DataType="boolean"
MustBePresent="false"/>
<Apply FunctionId="boolean-equal">
<AttributeValue
DataType="boolean">true</AttributeValue>
<VariableReference VariableId="$value"/>
</Apply>
</ForAny>
All the functions that take a bag argument are looping, but
the body of the
loop is either fixed by definition, as in boolean-is-in, or is
determined by
a single function argument, as in the higher-order bag
functions. By exposing
the loop variable and the loop body in the ForAny _expression_ I
can make the
body of the loop any arbitrarily complex _expression_. It's a
superset of what's
already there.
Regards,
Steven
Thanks,
Rich
On 8/2/2013 2:42 AM, Steven Legg wrote:
Hi Rich,
On 31/07/2013 5:39 PM, rich levinson wrote:
Hi Steven,
I have quickly gone thru your comments and prepared some
replies,
but have not had time to edit or ensure that all the
bases are covered.
I am providing just your comments and my replies to
each, leaving
the prev email contexts behind (or at least only in the
trailing
part of this email) in order to make the replies more
readable,
but if anyone is just jumping in now, then they should
probably
go back to the earlier emails to get the full context.
In any event, in summary, I think your comments have
advanced
the discussion and clarified the use case a bit more,
and I have
adjusted my replies as seemed appropriate. I think, as
you will
see way down below, that if you agree w the logic I am
using
to describe this situation, that my proposal, does, in
fact,
address the use case you have presented, however, we
would
then still have some more issues to address, but let's
see
whether you agree w what I have said here first.
Below, your comments abut the left margin, while all the
indented stuff is my replies.
Thanks,
Rich
I intended that there be another entity represented by
an Attributes
element and identified by the URI"http://foo.com". This
is a specific
organization associated with the access subject, which
is neither the
access-subject nor the resource. I could have conjured
up a new,
predefined category called "organization", but this
assumes that
the access-subject can only be associated with one
organization. The
"Attributes of Relations" thread is, in part, about how
to deal with
multiple instances of the same kind of entity. In this
case, association
with more than one organization. If each such
organization's Attributes
element used the same CategoryId, then this would be
interpreted as a
request for multiple decisions, which we don't want. So
to allow more
than one organization entity in the request context,
they each need
to have a unique CategoryId, which is really an entity
identifier in
their case, but I don't have the luxury of changing the
core schema
so CategoryId has to do double duty.
ok, but I would create a categoryId for each
organization role, such as employer-organization,
customer-organization, etc.
It's not hard to imagine an access subject being a
customer of more
than one organization, or even being employed by more than
one
organization, so role-specific category identifiers might
be enough
in some cases, but don't offer a general solution.
or if it were to be the case that there were
mult orgs in the same role, then:
org-1
org-2
etc. and could use regex type logic to parse
and select root and index.
From the policy perspective, category matching is always
by URI equality,
so I don't see where regexes would fit in.
keeping in mind that the values provided in the
request are "policy-driven" in the sense that
the PEP and/or requesting entity needs to know
what type of info needs to be provided in the
request.
That was what I intended. The CategoryId of that
Attributes element
being"http://foo.com".
ok, then we are probably talking about the same
concept. My main point is establishing a mechanism
to access attributes in other categories.
I understand that the presence of the XPathCategory XML
attribute changes
the actual data-type, but it's ugly to have the value
proclaim it is one
type when it is really a different type. I also realize
that you can't
fix that without breaking something else.
The basic "motivation" I had for coming up w this
is that: recognizing that this capability existed
for accessing "Content" elements and the Attributes
contained therein, in other categories than the
one containing the XPath _expression_, by using the
XPathCategory to identify the other category, it
seemed to me that this "unbalanced" the symmetry
of navigation, and so considered what would be
the minimum adjustment necessary to "undo the
imbalance", which is what the proposal is.
Also, I don't think it is any "uglier" than
the XPathExpression DataType not representing
the DataType of the attribute returned
by the XPathExpression.
However, by providing the DataType here, enables
the AttributeDesignator logic to test the
DataType consistently w all other attributes,
and the presence of the XPathCategory also
implies that the DataType of the referenced
attribute must have the same DataType as that
specified by the AttributeValue in the referencing
Attribute.
Well that's kind of my point. The AttributeDesignator
says get the organization
attribute from the access-subject, but the values that
are returned are actually
from the non-profit-organization attribute in a
different category. Or they
might actually be from a boolean organization attribute
in the access-subject
because the values didn't carry the XPathCategory XML
attribute. Or they might
be from some other attribute entirely because the PEP or
PIP put in something
other than what you intended. We can't look at an
AttributeDesignator and be
certain where the values it fetches will be coming from.
Control has passed from
the policy writer to the PEP and PIP.
Hmmm, I think I see your point, although I would
like to say
that this is the same case as the AttributeSelector.
It's the same case as an AttributeSelector with a
ContextSelectorId, but a
policy writer can choose not to use the ContextSelectorId.
The ContextSelectorId seems to be there to support
requests for multiple
decisions involving XML documents, so perhaps it wasn't
intended to be used
as a general redirection mechanism. Someone who's been in
the TC longer than
me might recall the rationale.
However, as I read the
AttributeSelector more carefully,
it seems to contradict itself, by first saying about
AttributeSelector@Category:
"This attribute SHALL specify the attributes
category of
the <Content> element containing the XML
from which
nodes will be selected."
Ok, this sounds like the Category that contains the
Content
that will be accessed by the XPathExpression, as
opposed
to any other Category that might contain the
Attribute
that contains the XPathExpression.
I assume this first statement is referring to the Path XML
Attribute,
which isn't an XACML attribute, or in one, and so doesn't
come with an
implied category.
But, it then goes on to say:
"It also indicates the attributes category
containing
the applicable ContextSelectorId attribute,
if the element includes a ContextSelectorId xml
attribute.
This would seem to say that both the Content and the
Attribute identified by the AttributeId in the
ContextSelectorId
xml attribute must be in the same Category.
I agree with your conclusion.
It then goes on to say about the ContextSelectorId
xml attr:
"The XPathCategory attribute of the referenced
attribute
MUST be equal to the Category attribute of
the attribute selector."
This seems to go full circle, rendering the
XPathCategory
xml attribute as being redundant and unnecessary,
It is redundant, but you have neglected to consider the
XPath-based functions,
which take xPathExpression values as arguments. There is
no current category
in the evaluation context of an XACML function, so it has
to be specified
somehow. The XPathCategory XML Attribute on the
xPathExpression value is
the mechanism to do that. My guess is that the
ContextSelectorId XML attribute
references an attribute with a value of the
xPathExpression data-type because
it was more convenient to use an existing data-type than
to invent a new
data-type that doesn't have the redundant XPathCategory.
> since
everything has to be in the
same Category. It's like
saying an Attribute needs to have a Category xml
attr
specifying the Category-Id of the Category it is in.
But the only reason it can say this about itself is
that it is in an Attributes element with that
Category,
and since this is already specified in the parent,
why specify it again in the child?
However, if we look at the defn of XPathExpression
beginning
on line 4045 App A.2, it says this about
XPathCategory:
"... an XML attribute called XPathCategory gives
the category of the <Content> element
where the
_expression_ applies."
This clearly implies that the XPathCategory contains
a Category that may be other than the Category in
which the Attribute containing the XPathCategory
is contained.
Considered from the point of view of an XPath-based
function there is no
Attribute or Category containing the xPathExpression value
and thus nothing
to be "other than". The statement in A.2 appears to be
directed towards the
use of xPathExpression values by the XPath-based
functions.
> Otherwise, what is the point of
going to the trouble of
specifying what a piece
of clearly redundant information that is already
part of the current processing context?
My understanding is that XPathCategory is supposed
to specify some "other" Category, so unless I am
reading the above text wrong, it would seem there
is some correction that needs to be made for the
intended use case to be possible based on the
description, which I think it currently is not.
I think the primary use case for xPathExpression is the
XPath-based
functions and that ContextSelectorId is a peripheral
addition. It does not
look like there was ever any intention to create a general
mechanism to
redirect from one category to another. We will have to
poll the TC to get
to the bottom of this question.
That being said, if the wording of the
AttributeSelector
text were to be changed to something more accurate,
such as
changing the last sentence of the Category
description to say:
"It ALTERNATIVELY indicates the attributes
category
containing the applicable ContextSelectorId
attribute,
if the element includes a ContextSelectorId xml
attribute."
i.e. the Category xml attribute of the
AttributeSelector
cannot both represent the Category of the Content,
AND the Category of the ContextSelectorId attribute,
unless they both happen to be in the same Attributes
element, in which case XPathCategory is unnecessary
to have in the ContextSelectorId attribute.
In addition, I think the last sentence of the
AttributeSelector@ContextSelectorId should say:
"The XPathCategory attribute of the referenced
attribute
MUST be equal to the Category attribute of the
ATTRIBUTES
ELEMENT CONTAINING THE CONTENT ELEMENT THAT THE
XPATH
IS INTENDED TO ACCESS."
Assuming what I have said is correct, then finally
we
are at the point where I can say that the same
situation
exists w the AttributeSelector, i.e. that the
AttributeSelector
also does not know what Category the content
containing the
AttributeValue it is looking for, or, for that
matter,
the path that is used to access that attribute
value.
Finally, given all that, I don't think the situation
is
as dire as you seem to indicate that you think it
is.
From my perspective, the PEP needs to be relied on
to
be responsible for assembling a valid Request. And
it
would seem to be the PEP's choice as to have an
Attribute
in one Category reference an AttributeValue in
another
Category.
As long as the metadata can be relied on, and
validated
appropriately, for example, DataType and Issuer, can
be specified in all 3 places: AttributeDesignator,
referencing Attribute, and referenced Attribute.
It is up to the PEP to assemble a valid construct
that can be relied upon by the PDP as part of
a PDP-PEP "contract" that is currently outside
the scope of the XACML specification.
It is the assembly that is the problem. The more that the
PEP and PIP are required
to do to achieve the desired effect of policy then the
less a policy writer can do
to change policy without it requiring re-engineering or
reconfiguration of the PEP
and PIP. I will come back to this point at the end.
Bottom line from my perspective is that if the
proper
governance is in place between the PEP and PDP then
what we are looking at here is simply distinctions
between the navigation within the Request structure
as opposed to any substantive value proposition
about one or the other being more reliable.
So, I don't think "control" has passed from the
policy
writer to the PEP, but only a choice by the PEP as
to how to package the information, any of which the
PEP must be responsible for, in terms of valid
content
and in terms of what the sources/metadata are of the
data that is contained in the Request.
Actually it does "know" because the XPathCategory in an
xPathExpression
value does not affect the processing by the
AttributeDesignator. The
AttributeDesignator will fetch values of the nominated
attribute and
data-type from the nominated Attributes element. If
those values have
the xPathExpression data-type, then they will have an
XPathCategory
XML attribute, but the AttributeDesignator will just
provide these XML
attributes in the bag of XACML attribute values that it
passes back.
It is the XPath-based functions that process the
XPathCategory XML
attributes.
The ContextSelectorId of an AttributeSelector will make
the AttributeSelector
pay attention to the XPathCategory XML attribute, but
section 5.30 of the
core specification says that the "XPathCategory
attribute of the referenced
attribute MUST be equal to the Category attribute of the
attribute selector"
ruling out the possibility of referencing into a
different Attributes
element.
Thus the indirection you are proposing for the
AttributeDesignator does
not have a precedent in the processing of
xPathExpression values by
attribute designators and selectors.
I think the previous comments address what you have
said here. In particular, I agree w what you have
observed about the AttributeSelector text, but I
think
that either the text is wrong, or the XPathCategory
attribute is superfluous as described above.
Clearly my proposal was based on the assumption that
the XPathCategory xml attribute was not superfluous,
which is why I proposed to extend its meaning.
Attribute flattening is described in the IPC profile.
...
Suppose there is a second boolean attribute of an
organization that we want
to use in decisions. Let's call it US-organization. We
can't reference it
using the same access-subject/organization attribute we
used for
non-profit-organization because that would be ambiguous.
We need two
access-subject attributes to do the job. Let's call them
organization-np
and organization-us. Allow that the access subject can
be associated with
zero, one or more organizations.
We can fetch the values the subject's organizations'
non-profit-organization
attributes using an attribute designator like:
<AttributeDesignator
Category="access-subject"
AttributeId="organization-np"
DataType="boolean"
MustBePresent="false"/>
We can fetch the values of subject's organizations'
US-organization
attributes using an attribute designator like:
<AttributeDesignator
Category="access-subject"
AttributeId="organization-us"
DataType="boolean"
MustBePresent="false"/>
We can ask a question like "is the subject associated
with a non-profit
organization and associated with a US organization ?"
using an _expression_
like:
<Apply FunctionId="and">
<Apply FunctionId="boolean-is-in">
<AttributeValue
DataType="boolean">true</AttributeValue>
<AttributeDesignator
Category="access-subject"
AttributeId="organization-np"
DataType="boolean"
MustBePresent="false"/>
</Apply>
<Apply FunctionId="boolean-is-in">
<AttributeValue
DataType="boolean">true</AttributeValue>
<AttributeDesignator
Category="access-subject"
AttributeId="organization-us"
DataType="boolean"
MustBePresent="false"/>
</Apply>
</Apply>
However, we have no way to ask the question "is the
subject associated
with an organization that is both a non-profit
organization and a US
organization ?" unless we know for certain that the user
is associated
with exactly one organization. The above "and"
_expression_ will work
in that case because we know that any and all values
returned for
organization-np and organization-us are properties of
the same
organization. However, when the subject can be
associated with one or
more organizations we don't know which organization-np
values belong
with which organization-us values. These are the
correlations that
get lost with attribute flattening and with your
proposal.
I think this is exactly the situation my proposal
can address.
Let's assume the subject is associated w two
organizations,
each of which is represented in the request by an
Attributes element. In order to be provided in the
same request as processed by the PDP, the two
Attributes elements would need different
Category-id's
such as "organization-1", and "organization-2"
<Attributes Category="subject-access">
<Attribute
AttributeId="organization-1-np">
<AttributeValue
DataType="boolean"
XPathCategory="organization-1"
>organization-np</AttributeValue>
</Attribute>
<Attribute
AttributeId="organization-1-us">
<AttributeValue
DataType="boolean"
XPathCategory="organization-1"
>organization-us</AttributeValue>
</Attribute>
<Attribute
AttributeId="organization-2-np">
<AttributeValue
DataType="boolean"
XPathCategory="organization-2"
>organization-np</AttributeValue>
</Attribute>
<Attribute
AttributeId="organization-2-us">
<AttributeValue
DataType="boolean"
XPathCategory="organization-2"
>organization-us</AttributeValue>
</Attribute>
</Attributes>
<Attributes Category="organization-1">
<Attribute AttributeId="organization-np">
<AttributeValue DataType="boolean"
>true</AttributeValue>
</Attribute>
</Attributes>
<Attributes Category="organization-2">
<Attribute AttributeId="organization-np">
<AttributeValue DataType="boolean"
>true</AttributeValue>
</Attribute>
<Attribute AttributeId="organization-us">
<AttributeValue DataType="boolean"
>true</AttributeValue>
</Attribute>
</Attributes>
In this case, I think one could formulate an apply
statement based on the 4 subject-access AttributeIds
that would could look at the user's association
w org-1 and org-2 and determine whether the
user belonged to an org that had both booleans
set to true.
This is the kind of _expression_ I think you mean:
<Apply FunctionId="or">
<Apply FunctionId="and">
<Apply FunctionId="boolean-is-in">
<AttributeValue
DataType="boolean">true</AttributeValue>
<AttributeDesignator
Category="access-subject"
AttributeId="organization-1-np"
DataType="boolean"
MustBePresent="false"/>
</Apply>
<Apply FunctionId="boolean-is-in">
<AttributeValue
DataType="boolean">true</AttributeValue>
<AttributeDesignator
Category="access-subject"
AttributeId="organization-1-us"
DataType="boolean"
MustBePresent="false"/>
</Apply>
</Apply>
<Apply FunctionId="and">
<Apply FunctionId="boolean-is-in">
<AttributeValue
DataType="boolean">true</AttributeValue>
<AttributeDesignator
Category="access-subject"
AttributeId="organization-2-np"
DataType="boolean"
MustBePresent="false"/>
</Apply>
<Apply FunctionId="boolean-is-in">
<AttributeValue
DataType="boolean">true</AttributeValue>
<AttributeDesignator
Category="access-subject"
AttributeId="organization-2-us"
DataType="boolean"
MustBePresent="false"/>
</Apply>
</Apply>
</Apply>
For this to work the PEP, PIP and policy writer have to be
in on the act,
and if that's the case, then this solution is
over-engineered. It would be
simpler to say to the PEP, PIP and policy writer that the
first associated
organization will use CategoryId "organization-1", the
second will use
"organization-2", and so on. The _expression_ could then be
written to directly
reference the organization categories like so:
<Apply FunctionId="or">
<Apply FunctionId="and">
<Apply FunctionId="boolean-is-in">
<AttributeValue
DataType="boolean">true</AttributeValue>
<AttributeDesignator
Category="organization-1"
AttributeId="organization-np"
DataType="boolean"
MustBePresent="false"/>
</Apply>
<Apply FunctionId="boolean-is-in">
<AttributeValue
DataType="boolean">true</AttributeValue>
<AttributeDesignator
Category="organization-1"
AttributeId="organization-us"
DataType="boolean"
MustBePresent="false"/>
</Apply>
</Apply>
<Apply FunctionId="and">
<Apply FunctionId="boolean-is-in">
<AttributeValue
DataType="boolean">true</AttributeValue>
<AttributeDesignator
Category="organization-2"
AttributeId="organization-np"
DataType="boolean"
MustBePresent="false"/>
</Apply>
<Apply FunctionId="boolean-is-in">
<AttributeValue
DataType="boolean">true</AttributeValue>
<AttributeDesignator
Category="organization-2"
AttributeId="organization-us"
DataType="boolean"
MustBePresent="false"/>
</Apply>
</Apply>
</Apply>
There is no need for the "organization-1-np",
"organization-1-us",
"organization-2-np" and "organization-2-us" attributes in
the access-subject
category and no need for a mechanism to redirect from one
category to another.
Whether you accept this simplification or not it is still
not a very scalable
solution. As the number of associated organizations grows,
the size of the
expressions and the number of defined attributes must also
grow. A policy
writer has to decide how many associated organizations
their policy will cater
for. Too few carries the risk of getting the wrong
decision. Too many means
wasted effort and excess verbosity.
So far we have only been talking about one kind of
association. Add in additional
kinds of associations and the number of combinations
quickly gets out of control.
For comparison, this is how I would do things using my
proposal.
The _expression_ to test whether the access-subject is
associated with a non-profit
organization looks something like this:
<ForAny VariableId="$org">
<!-- $org is bound to each organization URI in
turn -->
<AttributeDesignator
Category="access-subject"
AttributeId="organization"
DataType="anyURI"
MustBePresent="false"/>
<Apply FunctionId="boolean-is-in">
<AttributeValue
DataType="boolean">true</AttributeValue>
<Apply Function="attribute-designator">
<VariableReference VariableId="$org"/>
<!-- CategoryId -->
<AttributeValue
DataType="anyURI">organization-np<AttributeValue>
<!-- AttributeId -->
<AttributeValue
DataType="anyURI">boolean</AttributeValue>
<!-- DataType -->
<AttributeValue
DataType="boolean">false</AttributeValue> <!--
MustBePresent -->
</Apply>
</Apply>
</ForAny>
The request context would look something like this:
<Attributes CategoryId="access-subject">
<Attribute AttributeId="organization">
<AttributeValue
DataType="anyURI">http://foo.com</AttributeValue>
<AttributeValue
DataType="anyURI">http://bar.com</AttributeValue>
</Attribute>
</Attributes>
<Attributes Category="http://foo.com">
<Attribute AttributeId="organization-np">
<!-- was non-profit-organization -->
<AttributeValue
DataType="boolean">true</AttributeValue>
</Attribute>
</Attributes>
<Attributes Category="http://bar.com">
<Attribute AttributeId="organization-np">
<!-- was non-profit-organization -->
<AttributeValue
DataType="boolean">true</AttributeValue>
</Attribute>
<Attribute AttributeId="organization-us">
<!-- was US-organization -->
<AttributeValue
DataType="boolean">true</AttributeValue>
</Attribute>
</Attributes>
Now, if I want to test whether the access-subject is
associated with an organization
that is both a non-profit organization and a US
organization the _expression_ looks
something like this:
<ForAny VariableId="$org">
<!-- $org is bound to each organization URI in
turn -->
<AttributeDesignator
Category="access-subject"
AttributeId="organization"
DataType="anyURI"
MustBePresent="false"/>
<Apply FunctionId="and">
<Apply FunctionId="boolean-is-in">
<AttributeValue
DataType="boolean">true</AttributeValue>
<Apply Function="attribute-designator">
<VariableReference VariableId="$org"/>
<!-- CategoryId -->
<AttributeValue
DataType="anyURI">organization-np<AttributeValue>
<!-- AttributeId -->
<AttributeValue
DataType="anyURI">boolean</AttributeValue>
<!-- DataType -->
<AttributeValue
DataType="boolean">false</AttributeValue> <!--
MustBePresent -->
</Apply>
</Apply>
<Apply FunctionId="boolean-is-in">
<AttributeValue
DataType="boolean">true</AttributeValue>
<Apply Function="attribute-designator">
<VariableReference VariableId="$org"/>
<!-- CategoryId -->
<AttributeValue
DataType="anyURI">organization-np<AttributeValue>
<!-- AttributeId -->
<AttributeValue
DataType="anyURI">boolean</AttributeValue>
<!-- DataType -->
<AttributeValue
DataType="boolean">false</AttributeValue> <!--
MustBePresent -->
</Apply>
</Apply>
</Apply>
</ForAny>
This works for any number of organizations from zero
upwards. The request context
is the same as before.
In my proposal the redirection is explicit in the policy
and therefore under the
control of the policy writer. In the worst case, going
from the first _expression_
to the second _expression_, it might have been necessary to
configure the PEP, but
more likely the PIP, to know about and provide the
"organization-us" attribute.
This would be the same with your proposal, but with your
proposal, going from
testing just organization-np to testing both
organization-np and organization-us,
it is also necessary to configure the PEP or PIP to
properly construct the
"organization-X-np" and "organization-X-us" redirection
attributes for X equals
2 to whatever. These are not natural properties of an
access-subject, so they
are exceedingly unlikely to already be available (unlike
the "organization-us"
attribute in an organization entity). This is why it is
undesirable to have the
redirection under the control of the PEP and/or PIP. It's
not about correctness
or security (although having the PEP control redirection
probably increases the
attack surface for injection attacks), it's about greater
flexibility for policy
writers.
Regards,
Steven
In the case above, org-1 does not, but org-2 does,
so you could set up an Apply that did an OR
of org-1,org-2, and within each did and AND
of org-np, org-us to produce a true based on
the attrs contained in org-2.
Thanks,
Rich
On 7/30/2013 10:38 PM, Steven Legg wrote:
Hi Rich,
On 30/07/2013 3:00 PM, rich levinson wrote:
Hi Steven,
Apologies for taking so long to get back - as I
indicated at the mtg,
I was on vacation when this email arrived and simply
missed it.
I don't think I agree w your analysis/interpretation
of my proposal.
Let me try doing it more explicitly using your
example as a basis.
In the policy, the attribute designator contains, as
you have suggested:
<AttributeDesignator
Category="access-subject"
AttributeId="organization"
DataType="boolean"
MustBePresent="false"/>
I think where my differs begins in the attribute
directly targeted by
the designator, which is "organization" in the
"access-subject" category.
I think the attribute would look like this:
<Attribute AttributeId="organization">
<AttributeValue
DataType="boolean"
XPathCategory="resource"
>non-profit-organization</AttributeValue>
</Attribute>
where the only difference is I have provided the
Attribute envelope
w the AttributeId, plus I have changed the
XPathCategory to something
that looks more like a category than what you had
there (for which I
did not understand the motivation?: did you intend
that there be
a category called "http://foo.com"? this did not
seem to make sense
to me.).
I intended that there be another entity represented by
an Attributes
element and identified by the URI "http://foo.com".
This is a specific
organization associated with the access subject, which
is neither the
access-subject nor the resource. I could have conjured
up a new,
predefined category called "organization", but this
assumes that
the access-subject can only be associated with one
organization. The
"Attributes of Relations" thread is, in part, about
how to deal with
multiple instances of the same kind of entity. In this
case, association
with more than one organization. If each such
organization's Attributes
element used the same CategoryId, then this would be
interpreted as a
request for multiple decisions, which we don't want.
So to allow more
than one organization entity in the request context,
they each need
to have a unique CategoryId, which is really an entity
identifier in
their case, but I don't have the luxury of changing
the core schema
so CategoryId has to do double duty.
Now, if you are only going to use your proposal to
reference from one
predefined category into another predefined category,
then I don't see
the value in it. The attribute designator could just
be written to
directly access the other category instead, e.g.:
<AttributeDesignator
Category="resource"
AttributeId="non-profit-organization"
DataType="boolean"
MustBePresent="false"/>
In any event, given the way this example is set up,
we would now
look in the resource category "Attributes" element
for an attribute
w AttributeId="non-profit-organization" (again, I am
just following
the example, although the naming does not seem to
make sense,
which may have something to do w our differing
views).
<Attributes Category="resource">
<Attribute
AttributeId="non-profit-organization">
<AttributeValue DataType="boolean"
>true</AttributeValue>
</Attribute>
</Attributes>
So, basically, the motivation here, in the context
of this example,
is that for some reason, the <Attributes
Category="resource">
contains an attribute that the preparer of the
<Attributes Category="subject-access">
wants to refer to. Maybe this is just the way they
want to
set up their policies w the subject-access
containing attributes
that are associated w other "entities" than the
subject-access
itself. However, let's leave the motivation until we
have a
common understanding of the proposed mechanism and
then see if it addresses the attributes of relations
use case,
which would then be the motivation, if appropriate.
Now, to address the issues you raised:
First the summary statement would say
"then the attribute designator would fetch the
boolean value(s) of the
non-profit-organization attribute in the
resource Attributes category
of the Request"
So the statement begins the same, but now indicates
that the actual value
is obtained from another Attributes category
element.
That was what I intended. The CategoryId of that
Attributes element
being "http://foo.com".
Now, the issues:
* "The content of the attribute value in the
access subject (a URI)
doesn't conform to it's nominated syntax
(boolean)."
o You are correct that the DataType in the
AttributeValue
in the Attribute w AttributeId
"organization" does not
match the "DataType" of the
AttributeValue.
However, the reason is that the
"XPathCategory" xml attribute
of the AttributeValue semantically changes
the DataType
xml attribute to apply to the target
AttributeValue in the
Attributes element w the category
specified in the
current value. i.e. the AttributeValue of
the referencing
Attribute, which is the one referenced by
the
AttributeDesignator contains the
AttributeId of the
Attribute to be found in the Attributes w
the category specified by XPathCategory.
i.e. The presence of the XPathCategory
changes the
AttributeValue element from being a value
container
to being a value "referencer".
I understand that the presence of the XPathCategory
XML attribute changes
the actual data-type, but it's ugly to have the value
proclaim it is one
type when it is really a different type. I also
realize that you can't
fix that without breaking something else.
* "It's not obvious from the attribute designator
what attribute values
are being fetched."
o I disagree. The AttributeDesignator is
pointing to the
"access-subject" Attributes element, w
metadata
restrictions of AttributeId and DataType.
Because the Attribute contains an
XPathCategory this
indicates that the target value is not
here, but in
another Attributes element.
Well that's kind of my point. The AttributeDesignator
says get the organization
attribute from the access-subject, but the values that
are returned are actually
from the non-profit-organization attribute in a
different category. Or they
might actually be from a boolean organization
attribute in the access-subject
because the values didn't carry the XPathCategory XML
attribute. Or they might
be from some other attribute entirely because the PEP
or PIP put in something
other than what you intended. We can't look at an
AttributeDesignator and be
certain where the values it fetches will be coming
from. Control has passed from
the policy writer to the PEP and PIP.
This appears to me to be the same as is done
w
the XPathExpression, where, if
XPathCategory
is set to anything other than that of the
current
Attributes element, then the value is
retrieved
from a different Attributes element.
In that case, the XPathExpression, itself,
acts
as a kind of AttributeId, by pointing to a
specific
location in an external xml document,
namely,
the Content "document element", wherever
it
may be in the overall Request.
i.e. in the XPathExpression case, the
AttributeDesignator
also does not "know" in which Attributes
element that
the AttributeValue will be found.
Actually it does "know" because the XPathCategory in
an xPathExpression
value does not affect the processing by the
AttributeDesignator. The
AttributeDesignator will fetch values of the nominated
attribute and
data-type from the nominated Attributes element. If
those values have
the xPathExpression data-type, then they will have an
XPathCategory
XML attribute, but the AttributeDesignator will just
provide these XML
attributes in the bag of XACML attribute values that
it passes back.
It is the XPath-based functions that process the
XPathCategory XML
attributes.
The ContextSelectorId of an AttributeSelector will
make the AttributeSelector
pay attention to the XPathCategory XML attribute, but
section 5.30 of the
core specification says that the "XPathCategory
attribute of the referenced
attribute MUST be equal to the Category attribute of
the attribute selector"
ruling out the possibility of referencing into a
different Attributes
element.
Thus the indirection you are proposing for the
AttributeDesignator does
not have a precedent in the processing of
xPathExpression values by
attribute designators and selectors.
* "The correlations between different attributes
of the related entity
are lost, just as in attribute flattening."
o Ok, I'm not sure what you mean by "attribute
flattening",
but I do not believe anything is "lost" in
my proposal.
Attribute flattening is described in the IPC profile.
The only thing that changes here is that the
access is
"indirect", just as it is w the
XPathExpression that uses
XPathCategory and AttributeValue to
navigate to the
actual value.
i.e. in this case the "navigation" is also
using XPathCategory
to identify the Attributes element, but
instead of "XPath'ing"
to the target attribute value, it is
"AttributeId'ing" to the
target AttributeValue.
Bottom line is that nothing should be lost
because all the
info is retained either in the referencing
or the referenced
Attribute element, and the same metadata
controls can
be applied as in the direct case. It's
just the presence
of (the poorly named) XPathCategoryId
triggers a
slightly more complicated navigation
mechanism.
Suppose there is a second boolean attribute of an
organization that we want
to use in decisions. Let's call it US-organization. We
can't reference it
using the same access-subject/organization attribute
we used for
non-profit-organization because that would be
ambiguous. We need two
access-subject attributes to do the job. Let's call
them organization-np
and organization-us. Allow that the access subject can
be associated with
zero, one or more organizations.
We can fetch the values the subject's organizations'
non-profit-organization
attributes using an attribute designator like:
<AttributeDesignator
Category="access-subject"
AttributeId="organization-np"
DataType="boolean"
MustBePresent="false"/>
We can fetch the values of subject's organizations'
US-organization
attributes using an attribute designator like:
<AttributeDesignator
Category="access-subject"
AttributeId="organization-us"
DataType="boolean"
MustBePresent="false"/>
We can ask a question like "is the subject associated
with a non-profit
organization and associated with a US organization ?"
using an _expression_
like:
<Apply FunctionId="and">
<Apply FunctionId="boolean-is-in">
<AttributeValue
DataType="boolean">true</AttributeValue>
<AttributeDesignator
Category="access-subject"
AttributeId="organization-np"
DataType="boolean"
MustBePresent="false"/>
</Apply>
<Apply FunctionId="boolean-is-in">
<AttributeValue
DataType="boolean">true</AttributeValue>
<AttributeDesignator
Category="access-subject"
AttributeId="organization-us"
DataType="boolean"
MustBePresent="false"/>
</Apply>
</Apply>
However, we have no way to ask the question "is the
subject associated
with an organization that is both a non-profit
organization and a US
organization ?" unless we know for certain that the
user is associated
with exactly one organization. The above "and"
_expression_ will work
in that case because we know that any and all values
returned for
organization-np and organization-us are properties of
the same
organization. However, when the subject can be
associated with one or
more organizations we don't know which organization-np
values belong
with which organization-us values. These are the
correlations that
get lost with attribute flattening and with your
proposal.
Regards,
Steven
Hopefully this makes the
proposal a little more clear. I certainly
welcome any issues that you may raise, but I think
the current
issues are just indicators that clarification of the
mechanism
was needed as opposed to substantive functional
issues, which
may still be present, but I don't see them yet.
Thanks,
Rich
On 7/16/2013 8:33 PM, Steven Legg wrote:
Hi Rich,
On 13/07/2013 3:48 PM, rich levinson wrote:
To Steven, Mohammad, &
TC:
At yesterday's meeting, I mentioned that I
thought it might be possible
to implement the "relationship based access
control" reqts using the
current 3.0 spec, but also that I have not had
time to fully analyze
the reqts and the applicability of the soln.
In any event, I will explain things as far as I
have gotten looking
at this capability.
The first thing that brought this to my
attention was when I was
looking at examples using XPathCategory in the
3.0 spec. I was
aware that this had something to do w
AttributeSelectors, but
I was surprised to find one in an
AttributeDesignator (in Rule 1
in sec 4.2.4.1):
1090 [f60] <AttributeDesignator
1091 [f61] MustBePresent="false"
1092 [f62]
Category="urn:oasis:names:tc:xacml:3.0:attribute-category:resource"
1093 [f63]
AttributeId="urn:oasis:names:tc:xacml:3.0:content-selector"
1094 [f64]
DataType="urn:oasis:names:tc:xacml:3.0:data-type:xpathExpression"/>
1095 [f65]
The example is connected to the request in
section 4.2.2, and, sure enough,
there is an Attribute there that will be
resolved w this designator:
963 [e43] <Attribute
IncludeInResult="false"
964 [e44]
AttributeId="urn:oasis:names:tc:xacml:3.0:content-selector"
>
965 [e45] <AttributeValue
966 [e46]
XPathCategory="urn:oasis:names:tc:xacml:3.0:attribute-category:resource"
967 [e47] DataType="
urn:oasis:names:tc:xacml:3.0:data-type:xpathExpression"
968 [e48]
>md:record/md:patient/md:patientDoB</AttributeValue>
969 [e49] </Attribute>
There is nothing particularly remarkable about
this particular example,
however, it is fairly obvious that the
xpathExpression value could apply
to the <Content> of any <Attributes>
element in the <Request>, simply
by changing the value of XPathCategory to point
to the Category w
the desired value, such as category:action, or
category:access-subject.
Therefore we have a potential starting point for
referencing attributes
in some other category than the category that
the associated
Attribute element is in. i.e. in the above
example the Attribute
is in the category:resource collection, but its
value can be in
the <Content> element of either the
category:resource collection
OR any other <Content> element in some
other category:xxx
collection, simply by setting the Value of
XPathCategory
appropriately.
There is an additional benefit that the xpath
selection mechanism
can also be associated w the metadata of the
xpathExpression
Attribute, which I don't think is the case w the
plain vanilla
AttributeSelector (but this is a secondary note,
not the main
point of this discussion).
There are a couple of choices that I considered
for making this
mechanism more general:
1. We could allow XPathCategory to be used w
any
DataType, in which case the content of the
AttributeValue
would contain the AttributeId of the desired
Attribute
in the other Attributes
collection-category. I believe this
is functionally equivalent to the way the
xpathExpression
is used, if one considers the path in the
content to
effectively be the "id" of the attribute.
Also, it could
be the presence of the XPathCategory
attribute that
would trigger the semantic interpretation of
the value
as a reference instead of a normal value.
So if a value fetched by an attribute designator
has the XPathCategory
XML attribute (not the best name for it,
obviously), then the attribute
designator instead fetches the attribute nominated
by the original value's
content from the entity nominated by the
XPathCategory XML attribute for
the data-type specified by the attribute
designator ?
For example, if this is the attribute designator:
<AttributeDesignator
Category="access-subject"
AttributeId="organization"
DataType="boolean"
MustBePresent="false"/>
and this is one of the values of the organization
attribute in the
access-subject:
<AttributeValue
DataType="boolean"
XPathCategory="http://foo.com"
>non-profit-organization</AttributeValue>
then the attribute designator would fetch the
boolean values of the
non-profit-organization attribute in the access
subject's organization
entity.
If I've joined the dots correctly, then I see a
number of drawbacks:
- The content of the attribute value in the access
subject (a URI)
doesn't conform to it's nominated syntax
(boolean).
- It's not obvious from the attribute designator
what attribute values
are being fetched.
- The correlations between different attributes of
the related entity
are lost, just as in attribute flattening.
Regards,
Steven
2. I can't remember the
other choices at the moment, but
I think the above was the best one as I
recall.
So, I think the above should get the basic idea
across. I had
intended to go thru the emails on attributes of
relations
in more detail to determine if the above had the
potential
of meeting the reqts, but I have not had the
time to do
that, so I am asking the interested parties to
that discussion
if they think this approach would be viable, and
also a path
of minimal impact on the existing xacml specs.
Thanks,
Rich
--
Thanks, Rich
Oracle <http://www.oracle.com>
Rich Levinson | Internet Standards Security
Architect
Mobile: +1 978 5055017
<tel:+1%20978%205055017>
Oracle Identity Management
45 Network Drive | Burlington, Massachusetts
01803
Green Oracle
<http://www.oracle.com/commitment> Oracle
is committed to developing practices and
products
that help protect the environment
--
Thanks, Rich
Oracle <http://www.oracle.com>
Rich Levinson | Internet Standards Security
Architect
Mobile: +1 978 5055017
<tel:+1%20978%205055017>
Oracle Identity Management
45 Network Drive | Burlington, Massachusetts 01803
Green Oracle
<http://www.oracle.com/commitment> Oracle is
committed to developing practices and products
that help protect the environment
--
Thanks, Rich
Oracle <http://www.oracle.com>
Rich Levinson | Internet Standards Security Architect
Mobile: +1 978 5055017 <tel:+1%20978%205055017>
Oracle Identity Management
45 Network Drive | Burlington, Massachusetts 01803
Green Oracle <http://www.oracle.com/commitment>
Oracle is committed to developing practices and products
that help protect the environment
---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the
OASIS TC that generates this mail. Follow this
link to all your TCs in OASIS at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
--
Thanks, Rich
Oracle <http://www.oracle.com>
Rich Levinson | Internet Standards Security Architect
Mobile: +1 978 5055017 <tel:+1%20978%205055017>
Oracle Identity Management
45 Network Drive | Burlington, Massachusetts 01803
Green Oracle <http://www.oracle.com/commitment> Oracle
is committed to developing practices and products
that help protect the environment
--
Thanks, Rich
Oracle <http://www.oracle.com>
Rich Levinson | Internet Standards Security Architect
Mobile: +1 978 5055017 <tel:+1%20978%205055017>
Oracle Identity Management
45 Network Drive | Burlington, Massachusetts 01803
Green Oracle <http://www.oracle.com/commitment> Oracle is
committed to developing practices and products
that help protect the environment
--
Thanks, Rich
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
Next in thread →
Next in month →