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] Question regarding resource hierarchies


All,


As all standards, XACML allows a common vocabulary and interoperability between software implementations. But like all standards, XACML is not a product. To be utilized, one must choose a product that implements the standard. That product should be human-friendly on all levels.


TCP/IP is a great standard utilized by many products. One such product is Facebook. My kids don’t care about the standard(s) underneath. They care about the product. In the same fashion, if the users see XACML, you’re doing something wrong. They should see a very user friendly policy interface, developer API and configurable enforcement points. They should not care about the underlying policy persistence representation (which happens to be XML conforming to the XACML schema) or the request/response XML (or JSON) that conforms to a schema and profile.

 

Products take specifications and make them real. They allow users to connect to existing resource hierarchies or in some cases create resource hierarchies and define policies that are based in whole in part on those hierarchies.

 

I agree with David that the XACML spec does not create confusion. If kids had to learn to use the internet by reading the RFCs defining TCP, IP, DNS, HTTP, etc. only a few people with glasses and pocket protectors (like me, minus the pocket protector) would use the internet. It takes products that use the standard to bring boring specs to life.

 

 

Doron Grinstein  CEO  BiTKOO  818-985-4700 Ext. 31 www.bitkoo.com

 

 

 

From: David Brossard [mailto:david.brossard@axiomatics.com]
Sent: Friday, June 10, 2011 1:27 AM
To: Nick Duan
Cc: xacml-users@lists.oasis-open.org
Subject: Re: [xacml-users] Question regarding resource hierarchies

 

Hi Nick, all,

I wouldn't say XACML creates confusion. Much like any language it brings a grammar and you need to have some understanding of the grammar to be able to write efficiently / elegantly.

And the TC has thought about. This is what some of the profiles are about. XACML profiles bring best practices to certain areas e.g. export control, intellectual property, health regulation... These profiles are typically written / defined by people in the industry that faces this challenge which makes the profiles very well suited and focused.

Here are some of the profiles you could use (they are all listed at http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=xacml):

  • XACML v3.0 Hierarchical Resource Profile Version 1.0
    Committee Specification 01, 10 August 2010
  • XACML v3.0 Core and Hierarchical Role Based Access Control (RBAC) Profile Version 1.0
    Committee Specification 01, 10 August 2010
    • XACML v3.0: RBAC Profile (RBAC-Core, RBAC-Hierarchical) (pdf)
    • This profile provides attribute semantics and best practices on how to model the ANSI RBAC model - in other words implementing a role-based access control model using XACML rather than legacy systems. This profile is a good step to moving towards ABAC. In this profile, you can define roles and permissions assigned to roles. Different roles can inherit permissions from other roles much like it would happen in RBAC.
  • XACML v3.0 Privacy Policy Profile Version 1.0
    Committee Specification 01, 10 August 2010
    • XACML v3.0: Privacy Policy Profile (pdf)
    • This profile provides attribute semantics and best practices on how to model privacy concerns / privacy access control in XACML. This could apply to e-health where you want to make sure patient data privacy is preserved while still sharing medical information between practitioners.
  • XACML Intellectual Property Control (IPC) Profile Version 1.0
    Committee Specification 01, 17 August 2010
  • XACML 3.0 Export Compliance-US (EC-US) Profile Version 1.0
    Committee Specification 01, 17 August 2010
    • XACML v3.0 EC-US profile (pdf)
    • This profile comes from the fact the US Department of Commerce (and surely it applies to other countries) has set some laws about how data / goods can be exported from the US to other countries in the world. Whether you can export depends on the goods, the target country, the citizenships of the recipient and sender, etc... More info on export control at http://www.bis.doc.gov/licensing/exportingbasics.htm.

Have a look at the profile authors. They are usually experts in the field of the profile and can provide you more info.

As for more down-to-earth best practices on how to author / model XACML policies, bloggers, open source initiatives and vendors alike have provided webinars / training on the topic. Here are some links (Google helps):


Cheers,
David.

On Fri, Jun 10, 2011 at 2:58 AM, Nick Duan <nduan@verizon.net> wrote:

Certainly XACML makes writing policies flexible, but it also creates a lot
of confusions in the real world with how to create effective and consistent
policies, especially when there could be multiple ways to define access
control rules for the same set of resources.  I think taking the resource
structure into consideration in policy creation is a very reasonable
approach.  Does anyone know if any work published on XACML best practices?

Thanks!

ND


-----Original Message-----
From: Erik Rissanen [mailto:erik@axiomatics.com]
Sent: Thursday, June 09, 2011 4:05 PM
To: xacml-users@lists.oasis-open.org
Subject: Re: [xacml-users] Question regarding resource hierarchies

Laird,

Yes, you are right about that the core XACML specification does not say
anything about how resources operate, are set up, accessed and so on.
That is one of the strengths of XACML. It means that XACML can operate
on any type of resource in any kind of context.

You can compare this with databases and SQL. Regardless of whether you
are implementing a medical application, a financial application, or a
business for custom tailoring, you can still use the same technology and
language. For data storage it is SQL and for authorization it is XACML.

The role of setting up all this it that of the PEP, Policy Enforcement
Point, and the PIP, the Policy Information Point. These provide the
enforcement of the access and the attributes of the resource by which
the decision is made. The PEP and PIP are more environment specific than
the PDP and the XACML language itself.

In practice there are vendors who provide many of these components of
the shelf for you.

Best regards,
Erik

On 06/09/2011 09:12 PM, Laird Nelson wrote:
> This may be a bit off-topic for this list.  If so, please feel free to
> redirect me elsewhere.
>
> From my early-days understanding of the XACML specification, XACML
> specifies how PEPs and PDPs cooperate to render authorization
> decisions based on supplied resources and resource hierarchies (and
> subjects and a few other things).
>
> But none of this specification says anything, right, about setting up
> such resource hierarchies?
>
> So if, in my fictional world, I decide that I'm going to set some
> policies at the department level that should be applied to courses
> (i.e. that subjects employed by the school may edit their own
> departmental assets, of which a course is but one type), then it is
> incumbent upon me to figure out how to send along the proper resource
> to the XACML processors such that they can render a decision.
>
> I guess a final way to phrase my question is: XACML specifies the
> structure of the rules and policies involved, but says nothing about
> how the resources upon which those rules and policies operate are
> stored, set up, accessed, etc.
>
> Please do correct me if I am mistaken.
>
> Best,
> Laird


---------------------------------------------------------------------
To unsubscribe, e-mail: xacml-users-unsubscribe@lists.oasis-open.org
For additional commands, e-mail: xacml-users-help@lists.oasis-open.org


---------------------------------------------------------------------
To unsubscribe, e-mail: xacml-users-unsubscribe@lists.oasis-open.org
For additional commands, e-mail: xacml-users-help@lists.oasis-open.org




--
David Brossard, M.Eng, SCEA, CSTP
Solutions Architect
+46(0)760 25 85 75
Axiomatics AB
Skeppsbron 40
S-111 30 Stockholm, Sweden
http://www.linkedin.com/companies/536082
http://www.axiomatics.com
http://twitter.com/axiomatics



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