Re: [xacml-users] xacml v2, multiple resources but not multiple decisions
Hi Hao,
I think I understand what you are saying, which is that, as stated,
the additional
fk-* attributes in and of themselves have no ability to actually
pull in information
from those referenced resources?
If that is the case, then the way I would implement this is using
attribute finders,
which is implicit in the data flow diagram Fig 1, Sec 3.1 of both
2.0 and 3.0 specs.
In this situation, one would specify a "special" AttributeId in the
Policy, which
would not be present in the Request, and would have MustBePresent
set to true,
which would trigger Indeterminate processing, as described in sec
7.2.5, which
could then be used to read the foreign keys from the RequestContext
and get
any additional info needed.
If you were to specify in more detail exactly what attributes you
want to process
in the policy, then we can probably model the situation by having a
theoretical
relational data base that mirrors what the Policy requires.
Thanks,
Rich
On 6/27/2011 9:49 AM, hao chen wrote:
Hi Rich,
The problem is that there's no reference concept in XACML
policy. You will end define the same resource again and again
in the policy which cause big challenge to modify the policy
and also you will have to rebuild the same request again and
again to make different access decision query even the same
resource is used. If we have reference concept in XACML
policy, then you can just define one resource in the policy
and use different id as foreign key to reference them. Then
your comments will make a lot of sense. Using resource-id to
identify access resource is too restrictive to make XACML
implementation not efficient.
Best Regard
hao
From: rich
levinson <>
To: hao
chen <>
Cc:
Sent: Mon,
June 27, 2011 7:46:59 AM
Subject:
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