[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 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] 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> 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] 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]