Re: [xacml-users] xacml v2, multiple resources but not multiple decisions

Let me describe a use case in details as example. You may provide your insight on them accordingly.

 

We have the following resources:

application - collection application, payment application

within every application we have pages - account service page, payment service page, customer info page

within application's pages we have views - reward card view, bill payment view, customer contact view

within the views of the application's pages we have  fields - account balance, address

 

we may have 3 roles:

Customer representor 

Collector

Account manager

They have different access level to our applications and resources within our applications. Here are some examples:

Customer representor can access payment application.

Customer representor can access payment service page, customer info page of payment application and customer info page of collection application.

Customer representor can access bill payment view of payment service page of payment application & customer contact view of customer information page of collection and payment application.

Collector can access collection application. 

Collector can access reward card view of account service page of collection application.

Collector can only view the customer contact view of customer info page of collection application.

Account manager can access both collection application & payment application.

Account manager can change account balance on reward card view of account service page of collection application & on bill payment view of payment service page of payment application.
 

When we write the policies for those access rules, we need to define ids for those resources:

application - collection application, payment application

within every application we have pages - account service page, payment service page, customer info page

within application's pages we have views - reward card view, bill payment view, customer contact view

within the views of the application's pages we have  fields - account balance, address

 

All of the resources are 'resource-id' type of resources. Can we use xacml defined 'resource-id' to define the id for all above resource? Looks like we can't because based on xacml spec, 'resource-id' is used for the resource attribute to which the access decision is made; and those resources in some cases are used as access resource but in other cases those resources are used as context resources (non access resources). So, when we write the policy, it is better to define different id for those type of resources (not use 'resource-id'), such as

 

application-id for application

page-id for page

view-id for view

field-id for fields such as account balance or address

 

When we query application level access, we need to use 'resource-id' to reference the application (comply with xacml spec) and need to replace the 'resource-id' to application-id when goes through policies (because policies are written by using application-id.). But when query page level, view level, and field level access such as account balance, address, customer contact view, the application resource is the context resource. Then, in the query, we may use application-id and no conversion is needed. Here, I am talking about mapping ids not values.

 

My question is how this is going to work? It looks like need an engine in the middle to handle those conversions, but it is way too complicated. I think that using 'resource-id' to define the resource to which the access decision is made causes complexity and not necessary.

 

For Option 1, a resource actaully includes the access resource and all context resources which are all defined as attributes of the single resource. This way, you will see a lot of duplicated resource information defined in policies and they semantically mean the same things. You can define the id for context resources as you want. No rule is also kind of bad thing.

 

For Option 2, I do not see how it is going to work with xacml current spec.

 

Best Regard 

From: rich levinson <>
To: hao chen <>
Cc: 
Sent: Mon, June 27, 2011 12:42:13 PM
Subject: 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