Aspire ACL Structure

All ACLs for all documents are described in Aspire using a nested XML structure, as follows:

<acls>
  <acl name=""  access=""  entity=""  scope=""/>
  .
  .
  .
</acls>

For each ACL, the attributes are as follows:

  • @name – The name of the user or group to which the ACL is applied.
  • @access – The type of access for the named entity, either “allow” or “deny”
  • @entity – The type of named entity, either “user” or “group”
  • @scope – The scope of the ACL, either “global” or “???”

    Scope is only valid for NTFS ACLs

Enhanced Structure for Parent and Intersection ACLs

<acls>
  <parentAcl name=""  access=""  entity=""  scope=""/>
  <intersectionAcl name=""  access=""  entity=""  scope=""/>
</acls>

Note that <parentAcl>s and <intersectionAcl>s are two different methods for specifying an intersection between parent access control and individual document access control. The search engine publisher will need to choose which method they want to actually add to the indexes, based on what the search engine is able to support.

Mapping ACLs to the GSA

ACLs are specified in the GSA using metadata tags:

<meta name="google:aclusers" content=""/>
<meta name="google:aclgroups" content=""/>

The formula for specifying ACLs for the GSA from the Aspire ACLs is:

  1. Loop through all “acls/acl” elements from the Aspire metadata.
    1. Skip any acl with @access != “allow” or @scope != “global”
      1. (The GSA does not have deny ACLs at this time)
    2. If entity="user" output <meta name="google:aclusers" content="${@name} />
    3. If entity="group" output <meta name="google:aclgroups" content="${@name} />


  • No labels