Home →
Using LincDoc 3.1+ →
Security →
Using SQL Repository-Specific Security
13.8. Using SQL Repository-Specific Security
You can define your SQL repository to define the security policy for saved documents. Each time a document is saved (created or updated), a new security policy can be generated according to a set of rules defined within the repository. These rules are configured via the Security tab on the SQL repository's Configure dialog box.
Proceed to one of the following sections below for additional information:
Accessing the Repository's Security Options
The security options for a repository are set using the Security tab on the repository's Configure dialog box, which is accessed via the form's Admin dialog box.
- On the Admin dialog box, click the Repositories tab, and click the configuration button (wrench icon) that corresponds to the repository you want to configure.
- Once the Configure dialog box appears, click the Security tab.
The two, initial security options appear (unless you have already defined additional settings).
- Proceed to one of the following sections below, based on how you want your repository to determine security policies:
Inheriting Security Policies
When a document is saved to the repository, if the Do not set a security policy - inherit policy from the parent option is selected, the document will not have its own security policy. Instead, it will inherit the policy from the first ancestor that has a set policy (based on your repository's tree-like structure, which is similar to Windows Explorer). Therefore, the item's effective policy will be that of its parent.
If that document happens to create one or more subfolders based on its token-based name, those folders are also created with no security policy (that is, they also inherit their policy from the first ancestor that currently has a policy).
Generating Security Policies
When a document is saved to the repository, if the When saving a document, generate the security policy by evaluating the rules below option is selected, a policy will be generated for each item based on the rules you specify.
First, you need to determine the initial policy state. After that, you need to specify the rules for creating the policy. Both of these steps are described below.
Determining the Initial Policy State
When generating a policy for a document to be saved, the specific repository item can start with a fresh policy or apply rules to an existing policy.
Tip: In most cases, starting with a fresh policy is best.
- On the Security tab, click the When saving a document, generate the security policy by evaluating the rules below option.
Additional options appear in the bottom portion of the tab.
- Click one of the following options:
- Start with an empty policy. Allows you to create a new policy from scratch (beginning with a completely empty security policy).
- Apply the rules to the document's existing security policy. Allows you to set up a custom policy that builds on the policy of the selected item's first ancestor (the first ancestor that actually has a policy).
- Proceed to Specifying Policy Rules below.
Specifying Policy Rules
Once you have determined that you want to use rules to specify your security policy, you need to add and define the individual rules. When a document is saved to your repository, each rule is evaluated, in the order it is listed. If the condition evaluates to true, the selected privileges are used to update the selected target, as specified.
- On the far right side of the table's columns, click the + button.
An empty rule is added to the table.
- Select when condition will apply using one of the following options: Always, Never, or any available custom conditions (such as Display Spouse? in the example below).
For more information on creating a custom condition, see Creating and Editing Custom Conditions.
- When the rule's specified condition evaluates to "true", specify the action that will be taken in the +/- column:
- add. The specified privileges are added to any existing policy settings.
- remove. The specified privileges are removed from any existing policy settings.
- replace. The specified privileges replace any existing policy settings.
- Specify what will be impacted using the drop-down list in the target column.
The following options are available:
- owner. Applies only to the owner of the item.
- world. Applies to all users, groups, roles, and any existing tokens.
- user. Applies to a specific user, whom you need to specify.
- group. Applies to a specific group, which you need to specify.
- role. Applies to a specific role, which you select from the Role drop-down list that appears.
- token. Applies to a token that you need to define.
- Select the individual privileges granted by the rule using the corresponding check boxes.
You can also click the all or none links, below the list of privilege check boxes, if you want to quickly select all of the listed privileges or clear (uncheck) all selected privileges.
For more information on what is granted by each privilege, click here.
- If desired, add additional rules using either of the available + buttons, as highlighted below.
Note: You can also delete any added rules using the
- button.
- Return to step 1 and define additional rules, if necessary.
- When you are done adding rules, click save in the upper left corner of the Configure dialog box.
Selecting a User Target
If you select the user option from the target drop-down list, you need to select which user is affected by the rule you are defining.
- After you select user from the target drop-down list, the current user and the select user button appear.
- Click the select user button.
The Select user dialog box appears.
- Select the appropriate provider from the corresponding drop-down list.
- (optional) Add text on which to base your search in the text box below the Provider drop-down list.
- Click the search button.
A list of users within the selected provider is displayed.
- Click the desired user from the list that appears.
The user is highlighted when selected.
- In the upper left corner of the Select user dialog box, click select.
You are returned to the Configure dialog box, and the selected user appears above the select user button.
- Return to step 5 above.
Selecting a Group Target
If you select the group option from the target drop-down list, you need to select which group is affected by the rule you are defining.
- After you select group from the target drop-down list, the current group (if any) and the select group button appear.
- Click the select group button.
The Select group dialog box appears.
- Select the appropriate provider from the corresponding drop-down list.
- (optional) Add text on which to base your search in the text box below the Provider drop-down list.
- Click the search button.
A list of groups within the selected provider is displayed.
- Click the desired group from the list that appears.
The group is highlighted when selected.
- In the upper left corner of the Select group dialog box, click select.
You are returned to the Configure dialog box, and the selected group appears above the select group button.
- Return to step 5 above.
Defining a Token Target
If you select the token option from the target drop-down list, you need to name your token and, if desired, set an expiration date.
- After you select token from the target drop-down list, additional options appear, as shown below.
- In the Token type text box, enter a name for the token. This name will be used to identify the token throughout the rest of the LincDoc interface.
- If you'd like the token to only be available for a limited time, click the Expires check box, and specify how many minutes, hours, or days the token will be available using the corresponding options (highlighted below).
- Return to step 5 above.
For more information, see Example: Token-based Security Target.
Example: Specifying Rules
The scenario below shows a series of rules to evaluate. When saving a document to your repository, each rule listed below would be evaluated in the order they are listed, thereby building off of one another.
If the first condition evaluates to true, the rule adds the read privilege to the system/admin user target.
If the second condition evaluates to true, the rule replaces the read privilege from the first condition (which is also shown in the example below) with the read_by_id and write privileges to the same system/admin user target.
If the third condition evaluates to true, the rule replaces the read and write privileges to the system/Users group target. The policy for the system/admin user is unchanged, since it is not the target of the third condition.
If the fourth condition evaluates to true, the rule removes the write privilege from the system/Users group target. Again, the policy for the system/admin user is unchanged, since it is not the target of the fourth condition either.