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
- 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.
Thanks,
Rich
