Re: [xacml-users] xacml v2, multiple resources but not multiple decisions
Hi Hao,
The reason I made the analogy to the rdb case was that in an
rdb, if you define a primary key, then, let's say the name of the
primary key column in the account-balance table is "resource-id".
Similarly, the other resources would also have a primary key
column, whose names were "application-id", "page-id",
"view-id", "functional-area-id" respectively.
Now, if it was determined that the account-balance table had
relations to these other tables, the typical way to express this
relation would be to define a "foreign key column" for each
related table, which would be, for example, now an
account-balance table that looked like this:
account-balance:
resource-id (primary key)
fk-appl-id (foreign key) (values are "resource-id"
of appl-id tbl
fk-page-id (foreign key)
fk-view-id (foreign key)
fk-func-area-id (foreign key)
In rdb's this is not considered "inefficient" or redundant, but
simply
the price that is paid for defining the relationships.
A second suggestion I have is to check the multiple decision profile
for
xacml 3.0. It may have some guidance to set up a situation where you
can submit separate decisions for each resource type and come up
with one consolidated decision to return.
Thanks,
Rich
On 6/27/2011 1:07 AM, hao chen wrote:
HRich,
First, thanks for your comments.
The issue is that current xacml specification makes its
implementation inefficient and makes policy writing tedious
and contain duplicated information. In the example I
described, application id, page id, view id, and account id
which are both independant resources and also resources as
context of other resources. If we use resource-id as the
resource id to which the access decision is made, then for
different resource access request you have to use different
ids even for the same resource. For example, for application
access control, the application id uses resource-id; but
for page access, the application id has to use other id, such
as app-id and the page id uses resource-id. But they are
actually the same resource. When you write this kind of
policy, it is very confusing and difficult to read and
maintain. Why must we use resource-id as the resource id to
which access decision is made? Why should not allow to define
any resource id we want, and use an attribute of the resource
indicate whether or not the resource is for access decision?
Any way, option 1 works but is very urgly and not
efficient.
The use case of multiple resources but single decision is
very common. But I could not find an efficient way to make it
work by using xacml.
Best Regard
Hao
From: rich
levinson <>
To: hao
chen <>
Cc: "Tyson,
Paul H" <>;
Sent: Sun,
June 26, 2011 7:26:37 PM
Subject:
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