XACML Reference

Ambra Access Control

Simplified overview Diagram

Ambra Permission Service

Ambra contains a grants and revokes based permission service. The service allows explicit grants and revokes to be recorded on any resource-uri. These are persisted in the triple-store in 3 named-graphs:

  • GRANTS - contains <resource> <permission> <subject>
  • REVOKES - contains <resource> <permission> <subject>
  • PP - contains:
    • <permission> <topaz:implies> <permission>
    • <resource> <topaz:propagate-permissions-to> <resource>

In the above:

  • resource - is any uri that a subject requires permissions to use
  • permission - a uri denoting the type of permission
  • subject - a user or group that is requesting the permission

Note that this is a simplified version of XACML's usage. XACML allows for arbitrary number of attributes for resources, permission, subject (ie. not just the URI as in the permission service).

However the greatest advantage is that ambra services now can programmatically grant permissions or revoke permissions without having to define new XACML policies on the fly.

Implied Permissions

Implied permissions are a mechanism to reduce the number of entries. Currently this is configured via ambra's commons-configuration (see the keys: *ambra.permissions.impliedPermissions*).

Propagated Permissions

These entries are generated by ambra services to ensure that grants/revokes for a resource propagates down to its components. Typical usage is for grants from Annotation-URIs to propagate down to the corresponding Annotation-Body-URIs. Similarly for Articles and their components.

XACML PDP Configuration

Ambra does not prescribe a security policy. All it does as explained above is to generate grants/revokes. Rest of ambra services *never* makes any policy decisions based on what the permissions service has stored. It always goes to the PDP. So the administrator has the final say over the XACML policy in place.

The XACML PDP used by Ambra is configured using the PDPConfig.xml mechanism available in sun XACML. So this allows plugging in various finders and extension functions and gives maximum flexibility to customize the security policies.

The default PDP configuration file is located in the classpath of ambra webapp and is named /PDPConfig.xml. The default can be overridden by specifying the *com.sun.xacml.PDPConfigFile* system property. The property value is first looked up in the web-app and then as a file.

PDP configuration file defines the following:

  • A list of PDPs to use (standard-pdp or test-pdp in the default; but new ones can be defined)
  • A list of factories (for attributes, rule-combining algorithms and for functions)

The PDP definition also contains the following:

  • A list of Policy Finders. Policy finders can look-up policies from the class-path or from a URL
    • ResourcePolicyModule - looks up policies from the class-path. The policies to look-up are specified in the PDPConfig.xml file.
    • ResourceReferencePolicyModule - resolves policy id references from the class-path. The policies to look-up are specified in the !PDPConfig.xml. (Note: XML policies have ids and PolicySets can refer/include other Policies by their ids)
    • URLPolicyModule - looks up policies from a set of URLs that is configured in !PDPConfig.xml
    • URLReferencePolicyModule - resolves policy id references from a set of URLs configured in the !PDPConfig.xml. (XML policies have ids and PolicySets can refer/include other Policies by their ids)

XACML PEP Configuration

The PEPs are configured in the ambra configuration with the PDP to use. These configurations can be found at *ambra.services.xacml*. Note that these only refer to a name of the PDP defined in the PDPConfig.xml.

There are multiple PEPs in Ambra. Typically every service has its own PEP. eg. ArticlePEP, AnnotationPEP etc. All service calls are access checked by these PEPs. Typically the access check involves passing a resource and an action.

It is possible to extend this to pass as much information as possible to the PDP from the call context. All of these attributes then become available for use in XACML policies.

Default Ambra Policy

The default policy supplied by Ambra is based on the first-applicable combining algorithm and looks like this:

  1. deny-disabled-users (Deny disbarred users)
  2. permit-admin (User with a role 'admin' is allowed everything)
  3. permit-bootstrap (Allow everything if no 'admin' user exists yet)
  4. deny-inactive (Deny access to un-publisdhed articles)
  5. permit-irrevokables (Allow actions that are always allowed)
  6. deny-revokes (Deny explicit revokes defined in REVOKES model)
  7. permitted-anonymous-ops (List of ops that require no user login)
  8. permit-creator (Allow dc:creator of a resource all access)
  9. permit-self (Allow a user to update his/her own profile)
  10. permit-grants (Allow explicit grants defined in GRANTS model)
  11. deny-anonymous-users (Deny anonymous since the rest requires login)
  12. permitted-user-ops (List of operations that any user can perform)
  13. deny-all (Deny if none of the rules above matched)

Example for changing the policies used (assumes rpm install of Ambra)

  1. Edit /etc/sysconfig/ambra
    • add -Dcom.sun.xacml.PDPConfigFile=/etc/topaz/PDPConfig.xml
  2. Copy PDPConfig.xml from ambra webapp's WEB-INF/classes to /etc/topaz
  3. Create an /etc/topaz/policy directory and copy the policies from

webapp's WEB-INF/classes/policy directory

  1. Edit the /etc/topaz/PDPConfig.xml
    • change the policy finders from ResourceXXXX to URLxxxx
    • change the policy references to file:///etc/topaz/policy/xxx

You are done. Restart and now your policies are in effect. Now as a next step make some minor mods to existing polices and see that they are indeed in effect.

If you are updating the ITQL queries in a XACML policy please be aware that if they are wrapped inside a CachedBagFunction and the cache-id or the resource it caches changes, the corresponding change is also made in the mulgara filter resolver config. This way mulgara can invalidate the caches on an update to the values cached by the CachedBagFunction.

to do: More stuff to explain

Attachments