Nick, All:
In terms of Nick's original request, I think he was asking the
following:
"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."
where the emphasis is on multiple ways to define access control
rules for
the same set of resources.
My suggestion is to read the Hierarchical Resource Profile in some
depth
to understand how multiple hierarchies are represented.
http://docs.oasis-open.org/xacml/3.0/xacml-3.0-hierarchical-v1-spec-cs-01-en.pdf
In particular, clarifications have been added in XACML 3.0 to
include fully general
multi-rooted hierarchies, where each individual hierarchy is laid
over the same set
of resources.
There is also explanation of why DAG is insufficient to address this
requirement,
yet is a subset of this more general use case. The term, "polyarchy"
is also used
to describe this disjoint set of independent hierarchies applied to
a common
set of resources, which removes any constraints about "cycles" that
one
would encounter w DAGs.
With this model in mind, extremely complex use cases can be
represented
and factored into a collection of simple single hierarchy use cases
that are
combined within a single XACML PolicySet.
Thanks,
Rich
On 6/10/2011 9:11 AM, Erik Rissanen wrote:
Doron,
I think your facebook analogy is flawed.
We are talking about a developer securing a product/application,
not an end user of a consumer product. In case of your tcp/ip
example, it would mean that Nick is essentially asking about how
he can use tcp/ip to provide a web site for his customers. You
should not be referring Nick to facebook in this case. You should
be referring him to Cisco, or something else related to networking
technology. To be more specific, Nick should get hold of a product
which provides an XACML implementation for developers, integrators
and system administrators.
And, more so, in this case Nick was asking for best practices for
the XACML technology, that is, what kind of structures for
policies are good, and so on. As David pointed out, there are lots
of material out there.
Best regards,
Erik
On 2011-06-10 14:35, Doron Grinstein wrote:
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:]
Sent: Friday, June 10, 2011 1:27 AM
To: Nick Duan
Cc:
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: Hierarchical Resource Profile (pdf)
This profile provides
attribute semantics and best practices on how to model
access control policies on a set of resources structured
in a hierarchy.
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
IPC profile (pdf)
Similar to the above but
for intellectual property.
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):
WS02 Summer School on SOA
security: http://wso2.org/training?052411s
(includes some parts of XACML)
Axiomatics training: http://www.axiomatics.com/services/training.html
Rohati Systems had some XACML
video tutorials on youtube: http://www.youtube.com/user/rohatisystems
Free Kuppinger Cole webinars
Using Standards to manage
access to SOA and Cloud Services: http://www.kuppingercole.com/events/n40128
XACML Based Authorization -
Considerations for an Efficient and Flexible
Architecture: http://www.kuppingercole.com/events/n40119
Policy Based Access Control
with XACML 3.0: http://www.kuppingercole.com/events/n40111
Some blogs on ABAC &
XACML
http://www.analyzingidentity.com
http://www.webfarmr.eu.
Cheers,
David.
On Fri, Jun 10, 2011 at 2:58 AM, Nick
Duan <>
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:]
Sent: Thursday, June 09, 2011 4:05 PM
To:
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:
For additional commands, e-mail:
---------------------------------------------------------------------
To unsubscribe, e-mail:
For additional commands, e-mail:
--
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
