Re: [xacml-users] xacml v2, multiple resources but not multiple decisions
Hi Hao,
I have read over the problem description and comments and have a
couple
comments to make that may be useful.
For option 1, which I think is a perfectly legitimate
solution, I would
simply regard the additional resource-id's analogous to foreign
keys
in a relational database. As such one would define AttributeId's
for
such foreign keys in a consistent manner so that the Policy
could be
understood much like a SQL statement would be understood.
For example, it appears from the example given that you have 5
"resource-types": application, page-id, view-id,
functional-area-id,
and account-balance.
I would then assume that each of these resource-types has
their own collection of resource-id's, each of which
explicitly
identifies an instance of the respective resource-type.
I would then in the Resource collection of Attributes in the
request, use the identifier of the account-balance that was
being checked as the value for the Attribute with AttributeId=
"...:xacml:1.0:resource:resource-id".
I would then create some new AttributeId's for the foreign
keys,
for example:
"urn:example:account-balance:fk:application"
"urn:example:account-balance:fk:page-id"
"urn:example:account-balance:fk:view-id"
"urn:example:account-balance:fk:functional-area-id"
I would then assign the specific values of the instances of
these
resource-types as the AttributeValue's in the Request, i.e.
the
values of those resources' resource-id AttributeId.
I believe this is the general approach used in relational
databases, and
could be used here as well.
A second point is that the
AttributeId="urn:oasis:names:tc:xacml:1.0:resource:resource-id"
is a "universal AttributeId that can be used for any
resource-type;
Therefore, one already has the implicit problem that a
resource-id,
alone, cannot uniquely identify a resource unless it implicitly
contains
a "sub-identifier" indicating the resource type, which would
have to
be a convention of subdividing the resource-id string somehow,
for example having a "resource-type" namespace prefixing the
value
of the resource-id.
An alternative approach is to have a "companion" AttributeId
which
is used to identify the resource-type, which would thereby
qualify
the resource-id.
A third point is that I don't really understand option 2 in
the sense that
it sounds like you are passing in 5 independent "resource-id"s,
w/o
qualifying which one access is being requested to (as implied by
the parenthetical comment of resource 5 that says: "this is the
resource
to which the access decision will be made").
As a result, option 2 lacks a distinguishing mechanism for the
specific
resource to which access is being requested. By simply using
"resource-id"
to ONLY refer to the resource being accessed, one then
implicitly must
use another mechanism to refer to the other resource-id values
that
you want to include in the request, such as the suggestion(s)
made
above.
Let me know if you think this approach sounds reasonable.
Thanks,
Rich
On 6/24/2011 1:30 PM, Tyson, Paul H wrote:
Correction again. The v3 spec simply says that
resource-id means, “This attribute
identifies the resource to
which access is requested”.
Regards,
--Paul
From: Tyson,
Paul H
Sent: Friday, June 24, 2011 12:27
To: hao chen;
Subject: RE: [xacml-users] xacml v2, multiple
resources but not multiple decisions
Correction. I actually looked
at the v2 and v3 specs. The definition of
urn:oasis:names:tc:xacml:2.0:resource:resource-id that you
quoted does not appear in v3.
There is a
urn:oasis:names:tc:xacml:1.0:resource:resource-id
attribute id defined, but it appears to be used for XML
content in the request. I will raise this issue with the
TC to clarify the definition in v3.
“urn:oasis:names:tc:xacml:2.0:resource:resource-id” is not
mentioned in v3.
Regards,
--Paul
From: Tyson,
Paul H
Sent: Friday, June 24, 2011 12:18
To: hao chen;
Subject: RE: [xacml-users] xacml v2, multiple
resources but not multiple decisions
Hao,
I was thinking mostly of v3
since I have not worked with v2 in some time. I don’t
see how you can define new categories in v2.
And the definition of
resource-id attribute was changed in v3.
It looks like your only choice
when using XACML v2 is your Option 1.
Regards,
--Paul
From: hao
chen [mailto:]
Sent: Friday, June 24, 2011 12:06
To: Tyson, Paul H;
Subject: Re: [xacml-users] xacml v2,
multiple resources but not multiple decisions
Hi Paul,
From your opinion, looks like
Option 2 is not compliance with XACML specification.
Could you provide more
information on "auxiliary resource as a new
user-defined category"? I know subject has category
but not familiar with resource category. Example
will be appreciated.
For resource-id, here's the
section from the XACML spec v2:
2947 The
<Resource> element
MAY contain one or more <Attribute> elements
with an
2948 AttributeId of
“urn:oasis:names:tc:xacml:2.0:resource:resource-id”.
Each such
2949 <Attribute> SHALL be
an absolute and fully-resolved representation of the
identity of
2950 the
single resource to which access is
being requested. If there is more than one such
2951
absolute and fully-resolved representation, and if
any <Attribute>
with this
2952 AttributeId is
specified, then an <Attribute>
for each
such distinct representation of
2953 the
resource identity SHALL be specified.
All such <Attribute>
elements
SHALL refer
2954 to
the same single resource instance.
Does it mean the attribute resource-id which
identifies the resource to which the access control
decision is made?
Best Regard
From:
"Tyson, Paul H"
<>
To: hao chen <>;
Sent: Fri, June 24, 2011 10:34:51 AM
Subject: RE: [xacml-users] xacml v2,
multiple resources but not multiple decisions
I think this is a
limitation of the XACML implied ontology, both
in v2 and v3. I’ve run into this problem
also, and the path of least resistance is your
Option 1, which essentially “flattens” remote
attributes onto the singleton resource
instance allowed in a request. However, this
violates the natural semantics of your
enterprise ontology.
As a refinement of
your Option 2, you could use the class name
(type) of the auxiliary resource as a new
user-defined category. That would minimize
the direct coupling between the XACML
components, since they could all be informed
by the same ontology definition.
There are no strong
semantics associated with the resource-id
attribute defined in the spec, so you can
choose to use it as a unique key or identifier
for a resource, or not.
It would be good to
specify a variety of use cases illustrating
this problem so the TC could consider whether
to define a standard solution.
Regards,
--Paul
From:
hao chen [mailto:]
Sent: Friday, June 24, 2011 09:58
To:
Subject: [xacml-users] xacml v2,
multiple resources but not multiple
decisions
Hi,
My question is basically for the
situation where we need to make a decision
based on multiple resources.
We have an application
and use xacml v2 spec implementation to
control the access to the application
resources. We have a situation where the
access decision for a resource requires
multiple other resources as inputs.
For example, we have
the following resources:
application id
page id
view id
functional area id
account balance.
we would like to make
decision if an agent can modify the
account balance.
so we have a permission
as
a subject - agent, e.g.
plays account manager role
a resource - account
balance
a action - modify
But in order to make
the access control decision, we also need
to have other resources which are the
context to define what the account balance
references to. Those are
application id
page id
view id
functional area id
Those resources can
also be used separately, for example,
application id can be used to decide if
an agent can access the application, or
page id can be used to decide if an
agent can access a specific page.
We have 2 options to
modify about permission:
Option 1.
a subject - agent,
e.g. plays account manager role
a resource - has the
following attributes: application id,
page id, view id, functional area id,
and account balance
a action - modify
Option 2.
a subject -
agent, e.g. plays account manager
role
resource
1 - application id
resource 2 - page
id
resource 3 - view
id
resource 4 -
functional area id
resource 5 -
account balance ( this is the
resource to which the access
decision will be made.)
a action -
modify
I know Option 1 would
work with xacml v2 implementation. I
have the following questions for Option
2:
1. Can we make Option
2 as a valid use case in compliance with
xacml v2 spec, i.e. could we use xacml
v2 spec to define XACML policy and
request to achieve option 2?
2. From
implementation point of view, option 2
has advantage, i.e. for an access query
within the same context we do not need
to set all repeated attributes to create
a resource instead just create a
resource with a new attribute. Is this
really a advantage or is a wrong
impression.
3. For either Option 1
or Option 2, we have to use XACML spec
defined resource id -
urn:oasis:names:tc:xacml:1.0:resource:resource-id
to define the attribute for account
balance to which the access decision is
made. Am I right? For option 2, what id
should be used to define resource
- application id, page id, view id,
functional area id which can be used as
separate resource to make access
decision too.
Highly
appreciate your views on the issue.
thanks
hao