Home → Using LincDoc 3.1+ → Security → Using Document-Specific Security in a SQL Repository

13.7. Using Document-Specific Security in a SQL Repository

Document-specific security (or more accurately node-level security) allows you to configure access control for each node in a SQL repository individually, as you deem necessary for your LincDoc environment.

A node is simply an individual item in your SQL repository, and can be used to collectively describe a document, a file, or a folder. Each of these nodes can have an individual security policy applied to them, if desired.

Proceed to one of the following sections below for more information:

About Policy Inheritance Behavior in SQL Repositories

Although the common scenario is that a node inherits security controls from its parent if it does not have a policy set for itself, this default behavior can be altered, if desired. From the repository level, you can specify if security policies are always initially inherited (the default setting) or if policies are dynamically set based on rules you specify in the SQL repository.

For more information on defining SQL repository security policy settings, see Dynamically Defining a Security Policy. 

Accessing the Security Options

Document (node) security for SQL repository items is defined using the Security for dialog box, which is accessed from the Browse dialog box.

  1. Access the Browse dialog box using the browse button on the LincDoc toolbar.
    .
    For more information on using the Browse dialog box, see Files and Folder - Browsing and Security.
  2. Locate the document, folder, or file whose security information you want to specify.
  3. Right-click the item, and select security from the menu that appears.
    The Security for dialog box appears.
  4. Proceed to one of on the following sections below, based on what you are trying to accomplish:

Specifying a Node-Specific Policy

You specify a node-specific policy by first determining if a policy exists (if not, you need to create one), and then specifying the individual security types and access privileges.

  1. Access a node's security policy as described in Accessing the Security Options.
  2. Determine whether or not a policy has already been created for this node. If no policy has been defined, a message appears stating this fact.
  3. If necessary, click the create policy button.
    The "no policy" message disappears, the create policy button is relabeled clear policy, and the bottom portion of the dialog box becomes editable.
  4. In the type list on the left side of the dialog box, click the type whose privilege you want to edit. These types represent users or groups of users that can share privileges. By default, the following types are available:
    • everybody. Represents all users, groups, or roles (including the guest role) that can access the node, despite the provider. It is a large, all-inclusive group.
    • owner. Only applies to the current owner of the node. For more information on ownership or changing a node's owner, see Changing the Ownership of an Item.

    Note: You can also create custom types for specific users, groups, roles, or tokens. For more information, see Creating a Custom Security Type.

  5. In the Privileges for list on the right side of the dialog box, select the privileges that are granted for the selected type.
    Privileges are specific to the item on which the privileges are granted. Selected privileges show a check mark in the corresponding check box.
    The following privileges allow you to control each operation that LincDoc performs upon a SQL repository item:
    • add_child. Allows for the adding of a document, a folder, or file within the SQL repository.
    • delete_child. Allows for the removal of a document, a folder, or a file that resides within the SQL repository.
    • history_delete. Allows for the removal of an old (non-current) version of a document or file.
    • history_read. Allows for the viewing of the version history of a document or file.
    • modify_security. Allows for the modification of the owner or security rules of a document, a folder, or a file.
    • read. Allows for the reading of the content of a file or the list of files in a folder, if and only if the parent folder is readable.
    • read_by_id. Allows for the reading of the content of a file or the list of files in a folder, but, unlike read above, it applies to a specific node ID. Furthermore, the parent folder does not need to be readable.
    • read_data. Allows for the reading of a document's data.
    • write. Allows for the updating of the content of a document or file or the data within a document.

    The following privilege allows you to control some operations that LincDoc allows a user to perform with data retrieved from a SQL repository:

    • show_edit_ui. Allows for the accessing and using of the Data Entry View in LincDoc.
    In the example below, the history_delete and read privileges have been selected.
  6. If necessary, define privileges for additional types.
  7. Once all privileges for all types are defined, as needed for your particular scenario, click save in the upper left corner of the dialog box.

Creating a Custom Security Type

You can create a custom security type, if you need additional types beyond the everybody and owner types supplied by default.

For an example of when a custom type is useful, click here.

  1. Access an item's security policy as described in Accessing the Security Options.
  2. Click the + button adjacent to the type list.

    A list of options appears.
  3. Select one of the following options:
    • user. Allows you to assign privileges to a specific user.
    • group. Allows you to assign privileges to a defined group.
    • role. Allows you to assign privileges to a defined security role.
    • token. Allows you to assign privileges based on a defined token.
  4. Proceed to one of the following sections below, based on your choice in the previous step:

Defining a User or Group Security Type

If you decide to add a custom user or group type, you need to specify a provider and then select an existing user or group you want to use.

  1. Once you select the user or group option from the + button's menu, the Select dialog box appears.
  2. Select a provider that contains the user or group from the Provider drop-down list.
  3. Perform one of the following actions:
    • If you know which user or group you want to use, type the name (or a portion of the name) in the text box below the Provider drop-down list.
    • Leave the text box below the Provider drop-down list blank to search for all defined users or groups in the selected provider.
  4. Click the search button. A list of users or groups is returned.
  5. Click the user or group you want to use, and click select in the upper left corner of the Select dialog box.
    You are returned to the Security for dialog box, and a new entry is added to the type list.
  6. Assign privileges to the new type as described in Specifying a Node-Specific Policy above.

Defining a Role Security Type

If you decide to add a custom role type, you need to select the existing role you want to use.

  1. Once you select the role option from the + button's menu, the Select role dialog box appears.
  2. Click the desired role.
    You are returned to the Security for dialog box, and a new entry based on your role selection is added to the type list.
  3. Assign privileges to the new type as described in Specifying a Node-Specific Policy above.

Defining a Token Security Type

Important: This security type, accessed as described below, is considered an advanced LincDoc feature. In addition, this procedure is not the recommended way to set up token security. Contact LincDoc Technical Support for configuration assistance. 

If you decide to add a custom token type, you need to define the new token and determine whether or not it will have an expiration date.

This security type allows you to specify policies that can be used throughout the LincDoc interface. You can also set them to expire at a certain date and time.

  1. Once you select the token option from the + button's menu, the Token policy entry dialog box appears.
  2. In the Type text box, enter a name for the token. This name will be used to identify the token through the rest of the LincDoc interface.
  3. In the Token text box, view the automatically created token. You can alter this value, if desired, directly in the text box. You can also click the refresh button (to the far right of the text box) to have a new value generated.
  4. If you'd like the token to only be available for a limited time, click the Expires check box, and specify a date and time from the options that appear. When this specified date/time is reached, the token will no longer be valid.
  5. Click save.
    You are returned to the Security for dialog box, and a new entry, based on the defined token, is added to the type list.
  6. Assign privileges to the new type as described in Specifying a Node-Specific Policy above.

For more information, see Example: Token-based Security Target.

Viewing a Security Type's Settings

The everybody and owner security types, as well as any custom user, group, or role types, display definition information in the column adjacent to the type column in the type list.

 

For token types, the name of the token itself is displayed in the column adjacent to the type column in the type list.

In addition, you can click the "information" icon adjacent to the token's name to view the token's value and (if applicable) the expiration date and time.

 

Removing a Security Type

You can remove any defined security type, including the default everybody and owner types, by clicking the delete button that appears when you select a type in the type list.

Removing the Current Policy

You can remove a defined, document-specific policy using the clear policy button. You have the option of completely clearing the policy (and reverting to an inherited policy based on your SQL repository settings) or simply clearing all policy settings, but leaving the document-specific policy available for redefining.

  1. Access an item's security policy as described in Accessing the Security Options
  2. Click the clear policy button.

    The Clear policy dialog box appears.
  3.  Click one of the following options:
      • Delete policy and inherit from parent. Deletes all policy settings and re-inherits the security policy from the parent item. Basically, you are returning the security policy to its state before you created a custom document-specific policy, and the inheritance message reappears.
      • Clear all privileges from policy. Clears all selected privileges for the everybody and owner types, and deletes any defined custom types. The custom policy is retained (as it appears immediately after the create policy button is clicked), but no privileges are selected (all check boxes are cleared).

      The policy is updated.

  4. Click save to keep the cleared policy, or define a new policy as described in Specifying a Node-Specific Policy.

Changing the Ownership of an Item

You can change the user who is currently designated as a node's owner using the change owner button.

The current owner and the user's provider are displayed immediately below the Security for dialog box's toolbar.

Important: You must either be a superuser (as defined in your user settings) or possess the modify_security privilege to change a node's owner setting.

  1. Access an node's security policy as described in Accessing the Security Options
  2. Click the change owner button.

    Several options appear.
  3. Select one of the following options:
      • make me owner. You (the current user) are given ownership of the item.
      • select user. Allows you to specify a provider and specific user via the Select user dialog box. The selection procedure is identical to the one used when specifying a user for a custom security type.
      • no owner. No one will own the item. If the node previously had an owner, that owner's security policy will no longer apply.

      The ownership of the selected item is updated, based on your selection.

  4. Click save to retain the updated ownership setting.

Changing Back to the Previous Security Setting

You can return to the previously saved policy setting using the revert button.

For example, if you have defined a single policy, clicking the revert button will change back to the original, inherited policy. Additionally, if you have defined a policy and then cleared it (using the clear policy button), clicking the revert button will reapply the last defined policy.

Basically, this button returns to the previous policy definition (even if no policy was defined). It behaves similar to a standard undo button.

This page was: Helpful | Not Helpful
← 27.3. Creating an Email Template