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: Attributes for domain objects

I would like to be able to write policies for domain objects of several
types.  There will be a policy for documents, another policy for groups,
and another for membership in groups (yep, this is all following on the
previous message about the 'multi-group RBAC' domain).  It seems to me
that the right way to write policies/policy sets for these objects is to
restrict the Targets by resource type ("this is the document policy",
"this is the group policy", etc.)

The general question is whether there's some wisdom (hopefully tested 
wisdom =) on how to accomplish this.  I've had two basic thoughts, one 
of which is to try to mush the object type into the resource-id 
attribute, and the other of which is to add a resource-type attribute. 
I have what I think is a reasonably common database-backed application, 
where the the domain objects have identifiers which are (a) numeric and 
(b) broadly meaningless outside the application domain.

The mushing approach involves, e.g. generating resource IDs by 
prepending some short string singling out the type ("document-NNN", 
"group-NNN", "membership-NNN") and use the result as the resource ID. 
The policies can then use a regexp matching function to match requests 
to read or modify resources of the relevant type.

A variation on this would be to adopt an XML namespace-based URI
(or RFC 4151-style "Tag URI")  as the resource ID for each object (this
also appeals because we'll probably want to use RDF to describe the 
domain objects).

The other approach that suggests itself is to add a new Resource 
attribute specifying the type of thing the policy applies to.  Since our 
application lives in Java-land, the ready-to-hand approach here would be 
to use the fully qualified class names.  The PEP and the 
request-generating code all "live inside" our application, but we may 
want to open things up to outside requests some day.

How are other folks handling this sort of situation?

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