OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

xacml message

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

Subject: Fwd: [sunxacml-discuss] hierarchical resources


Attached is an e-mail sent to <sunxacml-discuss@lists.sourceforge.net>, 
the discussion mailing list associated with Sun's open source XACML implementation
at http://sunxacml.sourceforge.net.  It is concerned with use of
hierarchical resources, which is a current topic of discussion within the
TC.  Since the e-mail is not about the open source implementation, but 
is about use of the XACML language itself, I think it is more appropriate to 
discuss it here.

--- Begin Message ---

I have a better idea of what we're trying to do now, so I'll go ahead
and try to explain it in detail.

The ultimate goal:  issue a single request to a PDP with a role
identifier and a resource-id which is the root of a web application
(e.g. http://yossarian:8081/DeonticProto), and receive a Result back for
each resource the role is permitted to see.  Each view of the app (a URL
under the root) will have a page descriptor instance associated with
it.  This page descriptor file will be some XML vocabulary that is still
evolving (RDF might be involved).  It will basically define everything
in a page that is subject to access control, in a hierarchical manner. 
For example, a page can be split up into "container" objects, which can
then include items such as form elements or other data.  So, the
resource hierarchy we're dealing with is at the page level first (under
the root URL), and each page has its own hierarchical structure defined
by this descriptor vocabulary (an XML document).

I've created some XACML docs to really demonstrate this:

hierarchyRequest.xml includes a role identifier, the app root
resource-id, and an action which isn't that significant at this point
(it will probably always be 'read').  The resource:scope value is set to

This is the base policy set associated with the relying app.  It
contains references to other policy sets for each role (combining
algorithm set to only-one-applicable).  Looks like we'll need to create
our own policy finder to do this.

This is the policy set for role1; the role policy sets will include
references to other policy sets associated with each page that role is
authorized to see.

mainMenuPolicySet.xml is a page level policy set; it contains references
to policies about the "containers" within that page.

mainMenuContainer1Policy.xml has a Rule about a specific resource that
exists within that container.  The Rule will just associate 1 or many
roles with that resource.  I would imagine this is where a call to a
custom resource-finder would be, to reference a page descriptor doc...?

This approach could be all wrong with respect to how the XACML
hierarchical resource capability actually works, which is where I need
the most help and feedback.  

After all evaluations, we envision a Response document with Result nodes
referring to 1) the page id or URL, 2) page container ids and 3)
specific resources within those containers.  The XACML hierarchical
resource feature will probably dictate how we structure our policy-sets
and policies, as well as our resource descriptor model.

thanks in advance!
-bob daly


The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
sunxacml-discuss mailing list
--- End Message ---

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