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