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
