Content

Users Principle Configuration Role-Level Access Principle Configuration Departmental Security and SDC Access Principle Configuration Departmental Security for Data Sets and SDIWorkitems (Tests) Definitions Data Sets SDI Workitems (Tests) Granting SDI Access to Multiple Departments About Departments and Custody Interaction Between Role Level Access and Departmental Security Job Types Principle Configuration Changing Jobs Default Departments and Job Type Departments   SDI Security Principle Configuration Enabling SDI Security for an SDC Global and Owned Security Sets Example: Creating and Applying a Global Security Set Example: Creating and Applying an Owned Security Set Managing Global Security Sets Conditions for Editing and Deleting Global Security Sets Editing Global Security Sets in SDI List and Maintenance Pages Managing Owned Security Sets Conditions for Editing and Deleting Owned Security Sets Editing Owned Security Sets Security Set Templates and Auditing Granting SDI Access to Multiple Security Sets About Departments and Custody Database Connections Security Policy

 

Users	Top

Principle

A LabVantage "User" is someone who is granted access to (or can be referenced in) LabVantage.

During installation, LabVantage installs a customer-specific license (the labvantage.lic file) that defines the maximum number of each type of User you can create:

When you logon to LabVantage as the owner of the LabVantage schema, you are the (system) User. The (system) User cannot utilize all licensed LabVantage Modules, as these require a defined LabVantage User as described above. The (system) User is intended for use as an emergency administrator function (such as resetting passwords when it is not possible as a defined User).

Users are configured and maintained from the User List page (see Users and Roles).

Other settings for Users are defined in these areas of LabVantage:

Role-Level Access	Top

A "Role" defines a group of Users who are granted access to SDIs. Users "Jim" and "Mary" belong to the Role "Technicians", while "Bob" belongs to both "Technicians" and "Auditors":

Role Level Access is set for the Sample, Batch, User, and Project SDCs. This means that:

You define Role-Level Access in the SDC Maintenance page. You assign Roles to Users in the User Maintenance page.

Departmental Security and SDC Access	Top

"Departmental Security" is based on ownership of an SDI. What you can do with the SDI (the "SDC Operation") depends on who owns it. Both Users and Departments can own SDIs. We'll look at this by example. Assume these starting conditions:

"SDC Access" defines four "Access Types" that an owner can be granted:

Here is an example of how to setup SDC Access for Departmental Security:

1.

Go to the SDC List page (System Admin → Configuration → SDCs). Edit the SDC Maintenance Page for the Sample SDC: 1. Set "Access Control" to "Departmental". This activates Departmental Security for the SDC (in this case "Sample"). In the database, the "SecurityUser" and "SecurityDepartment" columns are added to the "s_Sample" table, which allows Departmental Security to associate a User and Department with a Sample. 2. If it not already present on the "Operations" tab, add the "list" SDC Operation. Users granted "list" access to the Sample SDC will be able view Samples in the Sample List page.

2.	Go to the Department List page (System Admin → Security → Departments). Add two Departments with the identifiers "DeptSS" and "DeptAA".

3.

Go to the User List Page (System Admin → Security → Users). Add two Users with the identifiers "ss" and "aa". 1. For User "ss", set the "Base Department" to "DeptSS". For User "aa", set the "Base Department" to "DeptAA". In the database, this populates the "SecurityUser" and "SecurityDepartment" columns in the "s_Sample" table to associate User, Department, and Sample. 2. Set the "Security Type" for both Users to "User". After saving these changes, return to the User List page. Select both Users, then click "SDC Access". In the Security Users page, enter O for the "list" operation. This assigns the "Owner" Access Type to both Users as described in Departmental Security Principle above.

You can also specify SDI ownership by using "Department View" to directly declare each User's Department:

1.

In addition to the "MOW" (Member-Owner-World) View in the SDC Access Security Users page, clicking "Display Options" lets you switch to "Departmental" View: Click the "Department View" radio button. For each User, this lets you specify Departments that will own SDIs. In order for "Departmental View" to work for a given Department, "Can Take Ownership" must be checked in the Department Maint page. The "MOW View" does not require this. Here we specify a unique Department for each User ("DeptSS" for User "ss" and "DeptAA" for User "aa"): NOTE:   1. Click the entry field. Departments that can take ownership are displayed. Select Departments from this list, then click "OK". 2. After clicking "Save", the selected Departments are associated with the User.

The DataSet and SDIWorkitem SDCs provide specialized functionality in their respective SDC "Access Control" Security/Update Options.

The following definitions apply to this discussion:

Note 1: "Primary" is the SDC for which data are entered. In this discussion, we assume this is the Sample SDC.

Note 2: "SDI Workitems" are also referred to as "Tests" (see Adding and Maintaining Tests).

Note that the DataSet SDC has no Role-Level Access options.

The SDIWorkitem SDC offers the "Honor Workitem" and "Honor Workitem and Primary" options:

As shown below, "Honor Workitem" allows the SDIWorkitem SDC to simply inherit the Departmental Security defined for the Workitem SDC. "Honor Workitem and Primary" also inherits the Workitem's Access Control, but additionally enforces the Departmental Security defined for the primary SDC:

Note 1: These options do not affect Data Entry.

Note 2: The SDIWorkitem SDC inherits the Access Control defined for the Workitem SDC. For example, if you define "Departmental" Access Control for the Workitem SDC and "Honor Workitem and Primary" for the SDIWorkitem SDC, that would be equivalent to defining "Departmental and Honor Primary" to the DataSet SDC.

The example configurations provided thus far assume that Departmental Security associates one Department to an SDI. However, multiple Departments may require access to the same SDI.

For example, assume that a site called "Laboratory-A" is also a Department. Users who access Sample-001 at "Laboratory-A" are therefore also members of that Department. These Users will generally retain sole access to Sample-001, i.e., they are the "owners" of the Sample and assume ultimate "responsibility" for the Sample. Security protocol dictates that Users in other parallel laboratories cannot have access to Sample-001. In this case, the Department "Laboratory-A" is specified in the SecurityDepartment column of the primary (Sample). No problems exist as long as Sample-001 remains in the posession of "Laboratory-A".

In the real world, Sample-001 will eventually be moved to a Repository. The Repository is also a Department with its own Users who require access to Sample-001. This is a typical BioBanking (ASL) scenario. During all Custodial Domain transfers in BioBanking ASL, the SecurityDepartment of the primary is changed to the Repository Department when Sample-001 is transferred. The result is that the original "owners" of Sample-001 can no longer access it. However, both "Laboratory-A" and the Department in possession require access. The problem becomes subsequently more complex if Sample-001 is transferred to a third-party testing facility. Suffice it to say that somewhere along the line, someone is going to lose access to the Sample.

To deal with these problems, the AddSDISecurityDept Action lets you specify multiple Departments that can access a Sample. This Action inserts a record into the SDISecurityDepartment table, which specifies additional Departments that can access the primary. Security is then defined by the union of all Departments specified in the SDISecurityDepartment table, plus all Departments specified in the SecurityDepartment column of the primary. A User who is a member of either of these Deaprtmentd can access the SDI. The DeleteSDISecurityDep Action lets you remove these records from the SDISecurityDepartment table.

With specific regard to Custody, the Department Maintenance page offers a "Retain Department Access" option that allows a Custodial Domain to retain membership access to the SDI (Sample) when Departmental Access Control is enabled for the primary SDC.

Interaction Between Role-Level Access and Departmental Security	Top

Roles are used to control 2 levels of access:

Departmental Security also provides two levels of access:

Roles relate to Departmental Security as follows:

Job Types	Top

A User who enters data may belong to only one Role and one Department. However, this same User may also assume managerial duties that are defined by other Roles in other Departments. "Job Types" let such a User dynamically change between these jobs. For example, such a User can be assigned two Job Types:

When a User logs on with one of these Job Types, he is assigned the Roles and SDC Access for that Job Type, and is directed to a startup page based on the Job Type.

Here is an example of how to setup Job Types:

1.

Go to the SDC List page (System Admin → Configuration → SDCs). Edit the SDC Maintenance Page for the Sample SDC: 1. Set "Access Control" to "Departmental". This activates Departmental Security for the SDC (in this case "Sample"). In the database, the "SecurityUser" and "SecurityDepartment" columns are added to the "s_Sample" table, which allows Departmental Security to associate a User and Department with a Sample. 2. If it not already present on the "Operations" tab, add the "list" SDC Operation. Users granted "list" access to the Sample SDC will be able view Samples in the Sample List page.

2.

Go to the Job Type List page (System Admin → Security → Job Types). Add a Job Type by clicking "Add": Enter values for these fields, then "Save". Field Description Job Type Enter a unique identifier for the Job Type. This example uses "Data Entry". Description Enter a textual description that will appear on the Job Type List page. Default Logon URL Enter the LabVantage URL (using Request Controller page-parameter syntax) that defines the logon page. In this example, we want the Sample List page to open at logon, so we enter: rc?command=page&page=SampleList Default Menu Default Sidebar To simplify this example, we discuss this later in Default Menu and Sidebar. Default Department To simplify this example, we discuss this later in Default Departments and Job Type Departments. Select the Roles that will apply to this Job Type, then "Save" again. This example uses the "Lab Data Entry" and "Analyst" Roles:

3.

Add a second Job Type by repeating step 2, but using these values: Field Value Job Type Manager Description Lab manager Default Logon URL rc?command=page&page=SystemAdminTramline Select the Roles that will apply to this Job Type, then "Save" again. This example uses the "Administrator" and "Lab Manager" Roles:

4.

Go to the Job Type List page (System Admin → Security → Job Types). Select the "Data Entry" Job Type, then click "SDC Access" (below left). In the Security Job Type page, enter O for the "list" operation, then "Save". This assigns the "Owner" Access Type as described in Departmental Security Principle above. Return to the Job Type List page and repeat the above procedure for the "Manager" Job Type:

5.

Go to the User List Page (System Admin → Security → Users). Add a User for the Job Type (this example uses the User identifier "bb"). Proceed as follows: 1. Set the "Security Type" to "Job Type". 2. Set the "Base Department" to an existing Department (we use "DeptBB" as an example). 3. Set the "Default Job Type" to "Data Entry". 4. Save these changes. 5. In the "User Job Types" detail (below), select the "Data Entry" and Manager" Job Types, then "Save" again . NOTES:   • The Security Types "User" and "Job Type" are mutually exclusive. "Job Type" dynamically synchronizes the User’s Roles and SDC Access through Departmental Security to that defined by the Job Type. Further editing of Roles and SDC Access is then disabled for the User: • Note the "Default Job Type" field. When multiple Job Types are assigned to a User, you can optionally specify a default Job Type that is used when this User logs on for the first time (if not specified, the first listed is the default). After that, the User can choose one of three logon options, as you will soon see. • Note the "Last Job Type" readonly field. This shows the last Job Type with which the User previously logged on (including the currently active session). This field is not populated until the User logs on with the Job Type.

6.

Logon as the User with the two Job Types (this is User "bb" in our example). As specified, the Sample List page opens with the Data Entry Job Type. Also, functionality is restricted to the Roles you assigned. SDC Access through Departmental Security functions as described in Departmental Security and SDC Access. Now you are ready to change jobs (see Changing Jobs below).

To change jobs, choose a different Job Type from the dropdown in the lower right corner of the screen:

The Job Type Manager page then provides a new logon form with the Username populated and the chosen Job Type selected. If "Require Re-Authentication" is set to "Yes" for the Job Type, a Password is required as shown at the left.

After providing the Logon credentials, you are then logged on with the new Job Type:

The session for the previous Job Type is auto logged out, functionality is now restricted to the Roles you assigned, and SDC Access through Departmental Security is now applicable to the new Job Type.

The Job Type for the previous logon is remembered, and all subsequent logons will default to last Job Type.

Clicking "Show my options" offers these logon alternatives:

• Always default to my last session Job Type • Always default to this Job Type (choose a Job Type from the dropdown) • Always let me choose a Job Type upon logon (prompts for a Job Type)

To change Job Type without re-entering password, set "Require Re-Authentication" for the Job Type to "No".

You can add dynamic Department memberships to Job Types. This lets a User logon with a Job Type and inherit the Department membership defined for that Job Type.

If you specify a "Default Menu" and "Default Sidebar" for a Job Type, when a User logs on or changes Job Types, these are used instead of the Default Menu and Sidebar defined in the GUI Policy or the Startup Menu and SideBar defined by the User Profile. Additional control is provided by the "Do Not Use Job style Start URL" property in the GUI Policy, which can ignore the Logon, Menu, and Sidebar defaults specified by the Job Type and use those defined by the GUI Policy or User Profile.

SDI Security	Top

SDI Security lets you grant a set of Users, Job Types (Users assigned the Roles and SDC Access for the Job Type), or Departments (Users in the Department) permission to perform a set of SDC Operations on selected SDIs. "Security Set" SDIs are used to define these permissions.

In the most simple use case, a Security Set defined for each Sample can grant the permissions shown.

A theoretical scenario shows the granularity achievable with SDI Security. Here, SDI Security can be used to provide different permissions on each Batch, as well as each Sample within a Batch.

In this case, typical options would be:

Before using SDI Security, you must setup the SDC (and optionally some associated SDI List pages) according to this example.

Go to the SDC List page (System Admin → Configuration → SDCs). Edit the SDC Maintenance Page for the desired SDC (in this case, Sample):

Now that the SDC is setup, you can create Security Sets for SDIs belonging to this SDC.

There are two types of Security Sets: "Global" and "Owned".

1.	Open the Security Set List page (System Admin → Security → Security Sets), then click "Add": Enter a unique identifier for the Security Set, then click "Save": The detail tab added to the Security Set Maintenance page now lets you setup permissions for Users (or Job Types or Departments) and SDCs:

2.

Here is where you grant permissions. Although this example adds Users, the procedure would be the same for adding Job Types or Departments. Accordingly, click "Add User" to add Users to the Security Set. Click "Add SDC" to add SDCs that have been enabled for SDI Security (as described in Enabling SDI Security for an SDC). This will create a selection matrix as shown below: Here are guidelines for use when granting permissions. Although these guidelines reference Users, they apply to Job Types as well. Example Security Set After Creation Example Security Set with Permissions   When you create a Security Set (whether Global or Owned): • The "All" User (1) and the creator of the Security Set (SysAdmin (2) in this example) are automatically added to the Security Set. These cannot be removed. • The "Admin" operation (3) is added to the "Security Set" SDC. Users who are granted the "Admin" permission can edit the Security Set. • The creator of the Security Set ("SysAdmin" (2)) is automatically granted the "Admin" permission. This cannot be changed. • The "Admin" checkbox is disabled for "All" Users ("All" indicates all Users in the system). When granting permissions, note that: • SDCs and other Users that you add to this matrix can be deleted by clicking "x". • Granting a permission to "All" disables permissions for all other Users. • The uppermost checkboxes (4) grant the relevant permission for every User. • Checking only "Edit" (5) automatically checks "List" and "Edit". • Checking only "Delete" (5) automatically checks "List" and "Delete". In this example, we grant the permissions shown at the right in the above illustration. When you create a Security Set (whether Global or Owned), be certain all permissions are granted to yourself. If you do not have all permissions, you will not be able to see any SDIs after you apply the Security Set to them.

3.	After saving, the Global Security Set is added to the Security Set List page: You can now apply this Global Security Set to any SDI in the relevant SDI List or Maintenance page.

4.

You can apply the Global Security Set from an SDI List page or an SDI Maintenance page. Since this example uses the Sample SDC, the two alternatives are: Sample List Page Open the Sample List page (LIMS → Samples → Manage). Select a Sample, then click "Manage Security Set": Sample Maintenance Page Open the Sample List page (LIMS → Samples → Manage). Select a Sample, then click "Edit". In the Sample Maintenance page, click "Manage Security Set": In either case, the "Manage Security Set Options" dialog opens (Sample List page shown below). This lets you choose how to apply the Security Set: Since you want to apply the Global Security Set you just created, select "Reference From: A Global Security Set". The Lookup page shows only Global Security Sets that have been created for the current SDC (which, in this case, is the Sample SDC). After selecting the Global Security Set, click OK in the "Manage Security Set Options" dialog. The Global Security Set is now applied to the selected Sample: We granted these privileges:   Permission User List Edit Delete SysAdmin x x x User aa x x   User bb x       Accordingly: • "SysAdmin" can see the Sample in the Sample List page, as well as edit and delete it. • "User aa" can see the Sample and edit it, but cannot delete it. • "User bb" can see the Sample, but cannot edit or delete it.   Users without permission to perform an operation are notified by a dialog such as this example, which is what "User aa" and "User bb" would see if they tried to delete the Sample:

1.

You can create the Owned Security Set from an SDI List page or an SDI Maintenance page. Since this example uses the Sample SDC, the two alternatives are: Sample List Page Open the Sample List page (LIMS → Samples → Manage). Select a Sample, then click "Manage Security Set": Sample Maintenance Page Open the Sample List page (LIMS → Samples → Manage). Select a Sample, then click "Edit". In the Sample Maintenance page, click "Manage Security Set": In either case, the "Manage Security Set Options" dialog opens (Sample List page shown below). This lets you choose how to apply the Security Set:

2.

Select "Create New: From Scratch". A matrix is created similar to the matrix described in step 2 of the Example for Creating a Global Security Set. The only exception is that the SDC is automatically added (and cannot be deleted), since Owned Security Sets are created in the context of a specific SDC (in this case, the Sample SDC): You can then add Users in the same manner as step 2 of the Example for Creating a Global Security Set, except that you do not have to add the SDC. All other behavior described in step 2 of the Example for Creating a Global Security Set also applies to Owned Security Sets.   For consistency in the examples, we grant the same permissions as the Global Security Set example. We therefore achieve the same effect: • "SysAdmin" can see the Sample in the Sample List page, as well as edit and delete it. • "User aa" can see the Sample and edit it, but cannot delete it. • "User bb" can see the Sample, but cannot edit or delete it. Once again (as noted in the Global Security Set example), if you are the creator of the Security Set, be certain all permissions are granted to yourself. Another notable difference between Global and Owned Security Sets is that Owned Security Sets have an "Owner SDI" column and an "Owner Check" flag: Option Description Owner SDI This is the SDI for which you created the Owned Security Set. The Owned Security Set is thereby said to have this "SDI context", since it was created specifically for this SDI. However, as you will see later, an Owned Security Set in one SDI context can also be referenced to other SDIs. Owner Check When enabled, the Owned Security Set can be edited only by its "Owner SDI", or in the Security Set List page. For example, suppose you apply the same Owned Security Set (with "Owner Check" enabled) to 2 different Samples: Owned Security Set Applied to: Owner SDI OSS-A Sample-001 Sample-001 OSS-A Sample-002 Sample-001 In this case, you can edit OSS-A only when Sample-001 is selected in the Sample List page, edited in the Maintenance page for Sample-001, or when you are in the Security Set List page. If you attempt to edit OSS-A for Sample-002, you will get a message to this effect: You are then given options described later in Editing Owned Security Sets. If you do not enable "Owner Check" for OSS-A, you will be able to edit OSS-A from either Sample-001 or Sample-002.

3.

Open the Security Set List page (System Admin → Security → Security Sets). You will see the Owned Seurity Set with the automatially-generated key [SDCId]_nnnnn, where [SDCId] is the identifier of the SDC, and nnnnn is the sequenced number of the Owned Security Set. Also note that the "Owner SDI' is shown, as well as the "Owner Check" flag.

These conditions apply to editing and deleting Global Security Sets:

•	Global Security Sets can be edited and deleted in the Security Set List page, but only by a User with the "Admin" permission for the Security Set, by or the (system) User. Violators are prompted by the dialog below. Clicking "Yes" lets you view the Security Set in read-only mode:
•	A Global Security Set cannot be deleted in the Security Set List page if it is applied to an SDI. You must delete the SDIs before you can delete the Global Security Set.

In the SDI List page (shown) or SDI Maintenance page, click "Manage Security Set" for an SDI that has a Global Security Set applied.

The "Manage Security Set Options" dialog informs you that this refers to a Global Security Set, and offers these options:

Option	Description
View the Security Set	Opens the Security Set in read-only mode.
Remove the Security Set Reference	Breaks the association between the Global Security Set and the SDI, effectively "un-applying" the Security Set by nulling the "Security Set" column of the SDI.
Create a Private Copy of the Security Set	Creates an Owned Security Set from this Global Security Set. This makes a private copy of the existing Global Security Set and applies it to the current SDI. The current SDI then becomes the "Owner SDI".
Create a New or Reference from an Existing Security Set	Opens the same dialog as that shown when creating an Owned Security Set: These options are available: Option Description Create New: From Scratch Lets you create a new Security Set and grant privileges as previously described in the examples. Create New: From a Security Set Template Creates a new Security Set from a Security Set Template. Create New: From an Owned Security Set Creates a new Security Set that is based on an existing Owned Security Set. Opens a Lookup page that shows Owned Security Sets (other than the one applied). Selecting one applies it to the SDI. Reference From: A Global Security Set Applies an existing Global Security Set. Opens a Lookup page that shows Global Security Sets. Selecting one applies it to the SDI. Reference From: An Owned Security Set Applies an existing Owned Security Set. Opens a Lookup page that shows Owned Security Sets (other than the one applied). Selecting one applies it to the SDI.

These conditions apply to editing and deleting Owned Security Sets:

•	Owned Security Sets can be edited in the Security Set List page, but only by a User with the "Admin" permission for the Security Set, or by the (system) User. Violators are prompted by the dialog below. Clicking "Yes" lets you view the Security Set in read-only mode:
•	Owned Security Sets cannot be deleted from the Security Set List page, since they maintain a context to an existing SDI that belongs to a SDC that has SDI Security enabled. If all SDIs having the same Security Set are deleted, the Security Set is automatically deleted from the Security Set List page.

There are two cases, depending on the Owner Check option.

•

Case 1 If Owner Check is not enabled for the Owned Security Set, or "Owner Check" is enabled and the selected SDI is the "Owner SDI", the "Manage Security Set Options" dialog informs you that this SDI is the owner, and offers these options from the context of the current SDI: Option Description Edit the Security Set Opens the Security Set and allows it to be edited. Remove the Security Set Reference Breaks the association between the Owned Security Set and the SDI, effectively "un-applying" the Owned Security Set as follows: When the Owned Security Set is owned by the SDI: • If the Owned Security Set does not reference any other SDI, it is removed. • If any other SDI refers to this Owned Security Set, only the owner details are removed from the Security Set (the "SecuritySet" column of the Owner SDI is nulled). The Owned Security Set then becomes a Global Security Set. When the Owned Security Set is referenced by the SDI: • Only the reference to the Security Set is removed, i.e., the "SecuritySet" column of the Owner SDI is nulled Create a New or Reference from an Existing Security Set Opens the same dialog as that shown when creating an Owned Security Set: These options are available: Option Description Create New: From Scratch Lets you create a new Security Set and grant privileges as previously described in the examples. Create New: From a Security Set Template Creates a new Security Set from a Security Set Template (see Security Set Templates and Auditing). Create New: From an Owned Security Set Creates a new Security Set that is based on an existing Owned Security Set. Opens a Lookup page that shows Owned Security Sets (other than the one applied). Selecting one applies it to the SDI. Reference From: A Global Security Set Applies an existing Global Security Set. Opens a Lookup page that shows Global Security Sets. Selecting one applies it to the SDI. Reference From: An Owned Security Set Applies an existing Owned Security Set. Opens a Lookup page that shows Owned Security Sets (other than the one applied). Selecting one applies it to the SDI.

•

Case 2 If Owner Check is enabled and the selected SDI is not the "Owner SDI", the "Manage Security Set Options" dialog informs you that this SDI is not the owner (as shown in Owner Check), and offers these options from the context of the current SDI: Option Description View the Security Set Opens the Security Set in read-only mode. Remove the Security Set Reference Breaks the association between the Global Security Set and the SDI, effectively "un-applying" the Owned Security by nulling the "Security Set" column of the SDI. Create a Private Copy of the Security Set Creates an Owned Security Set from this Global Security Set. This makes a private copy of the existing Global Security Set and applies it to the current SDI. The current SDI then becomes the "Owner SDI". Create a New or Reference from an Existing Security Set Opens the same dialog as that shown when creating an Owned Security Set: These options are available: Option Description Create New: From Scratch Lets you create a new Security Set and grant privileges as previously described in the examples. Create New: From a Security Set Template Creates a new Security Set from a Security Set Template (see Security Set Templates and Auditing). Create New: From an Owned Security Set Creates a new Security Set that is based on an existing Owned Security Set. Opens a Lookup page that shows Owned Security Sets (other than the one applied). Selecting one applies it to the SDI. Reference From: A Global Security Set Applies an existing Global Security Set. Opens a Lookup page that shows Global Security Sets. Selecting one applies it to the SDI. Reference From: An Owned Security Set Applies an existing Owned Security Set. Opens a Lookup page that shows Owned Security Sets (other than the one applied). Selecting one applies it to the SDI.

Create Security Set Templates in the Security Set Maintenance page as shown below.

Security Sets are Audit-enabled in the Security Set Maintenance page (shown above) and Security Set List page.

The example configurations provided thus far assume that SDI Security associates one Security Set to an SDI. However, multiple Security Sets may require access to the same SDI. This scenario for Security Sets is similar to that described for Departments in Departmental Security and SDC Access → Granting SDI Access to Multiple Departments.

To deal with this, the AddSDISecuritySet Action lets you specify multiple Security Sets that can access a Sample. This Action inserts a record into the SDISecuritySet table, which specifies additional Security Sets that can access the primary. Security is then defined by the Users, Job Types, or Departments associated with any of the Security Sets specified in the SDISecuritySet table, plus all Security Sets specified in the SecuritySet column of the primary. The DeleteSDISecuritySet Action lets you remove these records from the SDISecuritySet table.

The Department Maintenance page offers "Current Custodian Security Set" and "Relinquish Custody Security Set" options that allow you to specify the Global Security Set to associate with the SDI when a Department takes or relinquishes custody of the SDI (Sample).

Database Connections	Top

When a User logs onto LabVantage, LabVantage assigns a "ConnectionId" to the database connection. This is a unique identifier consisting of a large number (an integer of typically 13 digits). The ConnectionId is random and is not generated in any defined sequence. The Security Policy lets you define Session Management options for the connection.

Security Policy	Top

A system-wide Security Policy lets you determine the level of Web security desired, including: