Object Metadata

Overview

Object metadata allows you to store extended information on several Secret Server objects including users, groups, folders or secrets via the user interface or REST API. You can store most data types, including strings, Boolean values, numbers and users. You can combine this metadata into sections containing named fields of your defined types.

Unlike pre-existing object fields, this metadata is flexible and dynamic. No coding, structural changes, or database schema changes are required. The only constraint is a role permission that controls who can add metadata fields or sections, which is granular down to the sections level on a given entity. For example, users that can view a user might be allowed to edit the values in the "public" metadata section and users that can edit a user might be allowed to edit all the sections for that user.

Features

Secret Server object metadata features:

  • You can store user-defined metadata sections and field values on users, groups, folders, or secrets.
  • Sections and fields are defined once and can be used across any applicable object. This allows for a common description across all objects. For example, all the objects could have metadata fields for business owner, source system, and corporate department name.
  • Metadata fields are grouped or organized into sections.
  • When viewing metadata, only populated fields appear. Field names with blank values are never present.
  • You can define who can edit which sections via a role permission and through setting the View or Edit permissions for the object.
  • Each object maintains an audit history for all metadata fields, including previous values and who defined them.
  • Audit history is viewable as a basic line chart for metadata fields stored as numbers. This provides a historical value table, as opposed to an audit log.

Example Use Cases

There are many ways to use Secret Server object metadata, such as:

  • Defining common attributes from a corporate directory that are not available for a standard user, such as manager, hire date, or department.
  • Allowing defined users to add data to an object without allowing that user to edit the object itself. For example, the user can not edit a certain secret but can add notations on the secret that are useful to others accessing the object.
  • Storing external system link identifiers for integrations. For example, the employee ID from the HR system could be stored in the metadata for users. Integration jobs could then query this ID from the metadata and use it for synchronization.
  • Adding a department owner field on a folder to store which department owns it. For instance, the folder contains secrets for marketing as defined by the metadata field.
  • Avoiding users putting numerous items into the notes field on a secret, resulting in a disorganized mess. With metadata, those items could be stored in properly named fields. This organizes the notes and allows them to be easily searched without having to parse a block of text.

Adding Object Metadata

This instruction is on a user object. The process for folders, groups, and secrets is very similar.
  1. Go to Access > Users. The User Management page appears, listing several items/users:

  2. Select a user you want to edit. The user's page appears.

  3. Select the Metadata tab.

  4. Click the Add Metadata button. The Add Metadata popup appears:

  5. Click the Section Name dropdown list and select Add New Section. Additional controls appear:

  6. Type the section name in the New Section Name text box.

  7. (Optional) Type a description of the field in the Section Description text box.

  8. Click the Metadata Field dropdown list and select Add New Field, more controls appear: Metadata field name and Field type.

  9. Fill in the Metadata field name text box.

  10. Click the Field Type dropdown list and select the desired data type. For our example we chose Boolean.

  11. (Optional) Select the Value check box if you want the field to be pre-populated to true. This only applies to the Boolean data type.

    Boolean fields always appear later because they always have a value. Empty value fields do not appear.
  12. Click the Save button. The new section and metadata field appears:

    The section appears in the top-left, with the field right under it. A true or false value is visible denoting if the user has this test-field.

  13. Click the Add Metadata button again to add another field to the section. The Add Metadata popup returns.

  14. This time, click the Section Name dropdown list and select the section that you just created.

  15. Click the Metadata Field dropdown list box and select Add New Field.

  16. Type a name for the new field in the Metadata Field Name text box.

  17. Click the Field Type dropdown list to select Date / Time. Date and time text boxes appear. Add a date and time, do not leave them empty.

  18. Click the Save button. The new field appears on the Metadata tab:

  19. Add additional fields as required or desired. For our example, this makes the section, the test-field with its Boolean value, and the date / time field available for use across all Secret Server users.

Deleting Object Metadata

  1. Go to Access > Users. The User Management page appears, listing several items / users:

  2. Select a user you want to edit. The user's page appears.

  3. Select the Metadata tab.

  4. Select a section you want to modify fields for and then click Delete for the field you no longer need. A prompt appears double checking you want to proceed as deleting a field will also delete its history and cannot be undone.

Deleting all fields of a section will automatically delete the metadata section as whole. No warning prompt will be issued for this action, so double check before deleting all fields of a section.

Best Practices

How your organization uses object metadata requires some forethought, including:

  • Will you allow anyone to add metadata or only a specific set of individuals? This is controlled by applying the above mentioned role.
  • How do you want to standardize the naming of sections and fields? One user might call the same field business owner and another might call it subject expert if you do not establish the field nomenclature up front.
  • Do you want to create a "public" field section that is available to all users to edit, even those with read only permission on the object?