...
- Authoring XACML policies is an involved technical process, with behavior hinging upon the total policy set. For this reason policies/sets will be centralized, named and reused as much as possible. (Less is more)
- Administrators may choose to enforce a different set of XACML policies at any point within the repository tree.
- Metadata properties, such as ACLs or rights statements, can be used to avoid authoring more XACML.
- Node properties can determine the relevant policy within a set and the outcome from within that policy.
- Policies may depend upon an access role attribute.
- Policies (and/or sets of them) must be stored in the repository.
- Policies must be enforced on externally managed content, i.e. projected nodes within a federated node. (inc. filesystem connector)
- Must be able to filter authorize based on requesting I.P. address
- Must be able to authorize based on resource mixin types
- Must be able to authorize based on Hydra rightsMetadata datastream
- Must be able to authorize based on resource mimetype
Design Notes:
- Need to map XACML attributes to the repository, given a context node.
- JCR query or XPath?
- How to determine XACML data type?
- Can we write a extensible "attribute finder" based on relative JCR XPath?
- Should we implement a local or remote PDP?
- Should we use the PicketBox JBoss XACML Engine?
- PicketLink and PicketBox projects use the same XACML PDP. PicketLink is a larger umbrella project of security services.
- APIs to look at:
- org.jboss.security.xacml.sunxacml.finder.PolicyFinderModule is used to find a policy (or policy set) that matches the request evaluation context. Also used to lookup a policy that is referenced within a policy set by ID.
- org.jboss.security.xacml.sunxacml.finder.AttributeFinderModule is used to find attribute values when evaluating a policy.
- Constructing a policy set for the JBOSS engine:
- see JCR 2.0 16.3 and JBossLDAPPolicyLocator as an example.
...