Agreement Authorized Objects
Objects associated with an agreement are called authorized objects. For standard agreements, the authorized objects are added to the agreement when it is created or edited. For context-based agreements, all objects within the context in which the agreement resides are considered authorized objects.
There is no limit to the number of objects that can be associated with an agreement. Objects that do not have an appropriate security label value or that are outside of the scope of the agreement can be associated with the agreement, but they are not authorized until an appropriate security label value is applied or until the object or agreement is moved to an appropriate context. An object can be associated with more than one agreement. The agreements with which the object is associated can be viewed by adding the > table to the information page for the object. For more information, see
Security Information Tables. A user must have Read permission on the agreement to view it in the table.
For an agreement to provide clearance for one or more security label values set on an object, the object must have an Authorization Status of Active as shown in the Authorized Objects table for standard agreements. For context-based agreements, any security-labeled object that resides in the same context as the agreement is considered an active authorized object.
To be Active, the object must:
• Be in scope
◦ Standard Agreements: The object must exist in the same context as the agreement or in a descendent context.
◦ Context-based Agreements: The object must exist in the same context as the agreement.
◦ Standard Agreements: An authorized life cycle state or set of states can be specified for all authorized objects associated with an agreement. By selecting a specific life cycle state or states, you can limit the revisions of objects available to authorized participants. You must select at least one authorized life cycle state. By default, all life cycle states are authorized.
◦ Context-based Agreements: All revisions of a security-labeled object in the appropriate life cycle state and in the same context as the agreement are authorized.
To be authorized by the agreement, the object must be Active and the following criteria must be met:
• The object must have a security label value that was configured with the current agreement type, and, if the Select Authorized Security Label Values step was enabled, be one of the selected authorized security label values.
For example, in the
sample configuration if the State Export Agreement is the type being created or edited, objects with the License Required - State value are eligible to be authorized. Objects with the Do Not Export value could be associated with the agreement and would have an
Authorization Status of active, but the agreement could not authorize access to the objects because the label value has not been configured with the State Export Agreement type. Similarly, objects with the License Required - Commercial value could be associated with the agreement with an
Authorization Status of active, but because the License Required – Commercial value has not been configured with the State Export Agreement type, the agreement could not authorize access to the objects. An additional Commercial Export Agreement would need to be written to cover these objects. If the License Required-State value was later applied to an object with different security label values set, the agreement would only clear the Do Not Export value set on the object for users in the agreement’s authorized participants list. Those users would also need to be authorized for the rest of the security label values, either by being an authorized participant for the label values themselves, or by being an authorized participant in another agreement.