OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

xacml-users message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


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; xacml-users@lists.oasis-open.org
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:d95776@yahoo.com]
Sent: Friday, June 24, 2011 12:06
To: Tyson, Paul H; xacml-users@lists.oasis-open.org
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" <PTyson@bellhelicopter.textron.com>
To: hao chen <d95776@yahoo.com>; xacml-users@lists.oasis-open.org
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:d95776@yahoo.com]
Sent: Friday, June 24, 2011 09:58
To: xacml-users@lists.oasis-open.org
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

 

 



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]