Re: [xacml-users] xacml v2, multiple resources but not multiple decisions
Hi Hao,
Just a correction to 2nd sentence of last email, it should have
said:
Similarly, the other resources would also have a primary
key
column, named "resource-id", in tables, whose names were
"application-id", "page-id", "view-id", "functional-area-id"
respectively.
I hope this makes the analogy a little more clear.
Thanks,
Rich
On 6/27/2011 8:00 AM, rich levinson wrote:
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