Re: [xacml-users] xacml v2, multiple resources but not multiple decisions
Hi Hao,
I am not sure I understand your reply. I think there have been only
5 resource
data elements defined:
account balance
application id
page id
view id
functional area id
Based on earlier emails, these are all effectively "resource-id"
type
elements, in that instances of each of them identify distinct
resources.
And from what I understand, the actual resource being accessed
is a specific instance of "account balance".
In addition, the "context" in which account balance is being
accessed
is specific instances of appl-id, page-id, view-id,
functional-area-id.
Therefore I assume that the values of these 5 data elements are
being
passed in with the RequestContext for evaluation.
Where I am now uncertain is when you say:
"... we can separate policy writing and real resource
reference
defined in request and has an engine in the middle to get them
mapped for decision making process."
The reason I am uncertain is that if the 5 data elements have values
assigned in the original request, what is it necessary to map them
to?
Also, in the Policy, why can one not filter on each of these
attributes
separately? I believe the "action" only applies to the "resource"
which
has the "resource-id" value defined. The other resources are
auxiliary
context wrt account balance.
i.e. the request is:
"account manager" wants to "modify" a specific "account
balance"
AND context includes "appl-id", "page-id", "view-id",
"func-area-id"
I would think that the Policy could be determined based on this
alone,
by having Targets with range of users, range of actions, range of
account balances,
and ranges for the additional attributes.
The suggestion I gave w the attr-finders would be in case,
additional info needed
to be obtained for the account balance or any of the other resources
defined
as auxiliary context. However, the use case does not yet specify any
such conditions.
Thanks,
Rich
On 6/27/2011 12:28 PM, hao chen wrote:
Hi Rich,
Yes, it is kind of introducing reference concept into
policy such that we can separate policy writing and real
resouce reference defined in request and has an engine in the
middle to get them mapped for decision making process. We can
use the example I posted to have a try.
Best Regard
hao
From: rich
levinson <>
To: hao
chen <>
Cc:
Sent: Mon,
June 27, 2011 10:35:02 AM
Subject:
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