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


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 <rich.levinson@oracle.com>
To: hao chen <d95776@yahoo.com>
Cc: "Tyson, Paul H" <PTyson@bellhelicopter.textron.com>; xacml-users@lists.oasis-open.org
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; xacml-users@lists.oasis-open.org
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]