The secured repository adapter’s configurationFile property specifies an XML file that defines the behavior of the secured repository. The default name of this file is secured-test-repository.xml. Its format is similar to that of the definition file for the underlying repository, using the same item-descriptor and property tags to delimit information about individual item descriptors and their related properties. The DTD for this file is described later in this chapter, in DTD for Secured Repository Definition File.
The following table describes the attributes that can be defined for each item descriptor:
Attribute | Description |
|---|---|
| The ACL that applies to the item descriptor. This can contain any access right that applies to the item descriptor. The value of this tag is an ACL string, as defined in the ACL Syntax section. |
| The |
| This defines the name of the string property in the underlying repository that is to be used to store the name of the owner of a repository item. |
| This defines the name of the string property in the underlying repository that is used to store the ACL for an individual repository item. |
| An ACL fragment that is inserted into the default ACL for a newly created repository item. Typically this defines global access rights for administrators and limited access rights for the user base as a whole. This ACL fragment can contain any access right that applies to a repository item. |
| An ACL template that is used to generate an ACL fragment that applies to the owner (creator) of a newly created repository item. This is a standard format ACL string with a dollar sign ($) used to indicate the owner identity. No other identities may be used in the template. |
| An ACL template that is used to generate an ACL fragment that applies to each group that the owner (creator) is a member of in a newly created repository item. This is a standard format ACL string with a dollar sign ($) used to indicate the group identity. No other identities may be used in the template. Because a user may have a great many groups that they are a member of, it is suggested that this feature be used sparingly. For example, the ACC |
You can use a subset of these options to define ACLs for properties as well as item descriptors:
descriptor-acl
default-acl
acl-property
creation-base-acl
creation-owner-acl-template
creation-group-acl-template
See also the Secured Repository Definition File Tag Reference.
Group Membership
An identity is considered to be a group that the owner (creator) is a member of if the owner’s Persona lists it with its getSubPersonae() call. Exactly what is returned by this call varies according to the implementation of the User Authority.
The standard User Authority used here is implemented on top of the User Directory interface, and includes every Effective Principal of the user as a sub-Persona. For the Profile User Directory, this includes all Organizations, Roles, and Relative Roles of the user as well as all Organizations, Roles and Relative Roles of any Organization they are members of (explicitly or implicitly). For the Admin User Directory, this includes all Groups that the ACC account is a member of, but not the Privileges that the Group is assigned.
ACLs and Personae
When creating ACLs, the Personae that are used for user identities must be created by the same User Authority that is used by the secured repository. The User Authority must not be a proxy even if the Personae produced by a proxy test are equivalent to the Personae produced by the User Authority for which it is a proxy. This is because the identity name spaces used by a User Authority and its proxies may not be the same, and the ACL parser cannot support multiple identity namespaces.
