4 Designing a Security System

This section includes information on the following topics:

About Security Design in the Oracle Life Sciences Data Hub
Object Security Elements
User Interface Security
Security for Blinded Data
Example of Security Design
Design Decision Summary

About Security Design in the Oracle Life Sciences Data Hub

The Oracle Life Sciences Data Hub (Oracle LSH) security system determines which users can perform which operations on which defined objects (such as Programs and Tables) and outputs (such as reports). Users are allowed to perform an operation on an object or output when they:

belong to a user group that is assigned to the object or output either explicitly or by inheritance
and are assigned to a role within that user group that allows the operation on the object

You must design and set up a security system before you can use Oracle LSH.

To create an Oracle LSH security system you must do the following:

Design an organizational structure, or set of containers—Domains, Application Areas and Work Areas—to contain definitional objects(see Chapter 3, "Designing an Organizational Structure"). If you grant security access to user groups at the Domain, Application Area, and Work Area levels, the user group assignment automatically cascades to all contained objects. Design your security system in conjunction with your organizational structure to take advantage of this feature and minimize the number of user group assignments you need to make to individual objects (see "User Group Assignment by Inheritance").
(Optional) Define one or more subtypes for any of the predefined object types; for example, Clinical Outputs and Financial Outputs. You can then assign different privileges to different roles on different subtypes of the same object type; for example, allow statisticians to view Clinical Outputs but not Financial ones. Subtypes are also used to differentiate classification requirements (see Chapter 5, "Designing a Classification System for Searching and Browsing"). One subtype is predefined for each object type.
Design a set of roles. A role consists of a set of privileges: operations allowed on object subtypes. Some roles should reflect professional job descriptions at your company. Other roles should cover specific Oracle LSH responsibilities such as breaking data blinds. Users can have multiple roles in the same user group and different roles in different user groups. See "Roles".

Predefined application roles determine user access to the user interface (UI) but are not used in the security enforcement algorithm for defined objects or outputs. See "User Interface Security".
Design and create a set of user groups, each with a set of roles, and assign them to Domains, Application Areas, or Work Areas. See "User Groups".

To complete the security system you must create a user account for each person who will use Oracle LSH and assign at least one user to be the group administrator for each user group. The group administrator then assigns users to roles within the group. Each group administrator must then add users to his or her group and assign users to roles within the group.

You can add organizational containers, object subtypes, roles, and user groups, as well as users, over time as necessary.

Note:

In this chapter the word "object" is used to apply to object definitions and object instances. Users get security access and privileges on both definitions and instances in the same way. However, you can define different security requirements for each because they are distinct object types. For example, you can give a Definer privileges on Program definitions as well as instances, and give a Consumer access to Program instances only.

Object Security Elements

The Oracle LSH security system is based on objects subtypes, roles, user groups, and user accounts. Object types and the "Default" object subtype for each object type are predefined. Defining additional object subtypes is optional. You must define all the other elements. Instructions are included in "Setting Up the Security System" in the Oracle Life Sciences Data Hub System Administrator's Guide. The elements are described in the following sections:

Object Subtypes
Roles
User Groups
Users

Figure 4-1 Logical Representation of the Object Security Elements and Their Relations

Description of ''Figure 4-1 Logical Representation of the Object Security Elements and Their Relations''

As shown in the above diagram, object security elements have the following relations:

Each object type defines which operations can be performed on objects of that type.
Each object type must have at least one object subtype.
Object subtypes inherit characteristics from object types (namely allowed operations).
Each object is of one and only one subtype.
A role specifies which operations can be performed on an object of a given subtype by a user with that role (in a user group assigned to the object).
User groups support roles.
A user is assigned to a user group by assigning him or her to one or more supported roles in the user group.
User groups are assigned to objects and users gain access to an object through one or more user groups assigned to the object. The operations they can perform on an object depend on the roles they have in user groups assigned to the object.

Object Subtypes

Oracle LSH ships with predefined object types, including Program definitions, Program instances, Table definitions and instances, Report Set definitions and instances, and so on. Each object type includes a set of operations allowed on objects of that type; for example, Modify or Submit (for a complete list, see Appendix A, "Object Types with Operations"). One subtype (called "Default") is shipped for every object type.

All user-defined objects must be created based on an object subtype. An object's subtype helps determine its security and classification requirements. If you choose to, you can create additional subtypes; for example, Clinical and Financial. You can then differentiate security and classification requirements for different subtypes of the same object type.

For example, you can create two subtypes—Clinical and Financial—for Outputs. You can then assign different roles to the same operations on the two subtypes, so that some people can view financial reports but not clinical ones, and others can view clinical reports but not financial ones.

Subtypes and Security

Object subtypes have the same set of allowed operations as their parent object type. You must create a set of roles and assign each role to a set of operations on object subtypes. Users with a particular role can then perform the operations on the subtypes specified for the role, if the user group in which they have the role is assigned to the object.

If you create additional subtypes, you can assign different roles to their operations. For example, you might want to allow different people to view clinical and financial reports. To do this, you must create the appropriate roles and assign them to the appropriate operations on only the appropriate object subtype. For example:

Give the Financial Officer role privileges on the Financial Output subtype but not the Clinical Output subtype.
Give the Statistician role privileges on the Clinical Output subtype but not the Financial Output subtype.
Give the Trial Administrator role privileges on both Output subtypes.

Subtypes and Classification

Oracle LSH uses classifications to help users find objects through searching and browsing. You assign classificationhierarchy levels to subtypes to determine the classification hierarchy levels to which an object of that subtype can and must be assigned. For example, you can require that Financial Outputs be classified to the Fiscal Year > Quarter > Month hierarchy but Clinical Outputs be classified to the Project > Study > Site hierarchy.

See Chapter 5, "Designing a Classification System for Searching and Browsing" and specifically "Assigning Classification Levels to Object Subtypes" for further information.

Subtype Inheritance

When a Definer creates an object, the object inherits its parent's subtype by default, if that subtype exists for its object type. The Definer can change the subtype as necessary if there is more than one subtype for the object type. For example, if a Definer creates a Report Set definition in an Application Area whose subtype is Clinical, the Report Set inherits a subtype of Clinical if you have created a Report Set subtype called Clinical. If not, the report Set definition is created with the subtype designated as the default for Report Set definitions—either the shipped subtype called Default or another subtype you designate as the default for Report Set definitions.

Definers create Report Set instances in Work Areas, so Report Set instances inherit their subtype from the Work Area, if the same subtype exists for Report Set instances.

See Appendix B, "Object Ownership" for information about all parent/child object relationships.

Roles

A role consists of a set of privileges: operations allowed on a set of object subtypes. A single user can have any number of roles, and can have different roles in different user groups. You must assign roles to user groups and to users within user groups.

Roles Based on Job Description

Most of the roles you define should correspond to a professional role such as Statistician or Data Manager, and allow the appropriate operations on appropriate objects for that job description. For example, the Statistician role might have View and Submit privileges on Clinical Report Sets only, while a Data Manager or Programmer might have full privileges on all types and subtypes of object definitions and instances.

Consumers need to be able to run and view reports. For this they need the Submit privilege on Execution Setups and the View operation on outputs.

Some Consumers may need to create data visualizations using Oracle Business Intelligence Enterprise Edition. These people need View privileges on Business Area instances and Read Data operations on Table instances to have access to Oracle LSH data.

Programmers (Oracle LSH Definers) need many privileges. They need to be able to run and view reports as Consumers do. In addition, they need at least View privileges on Domains and Application Areas in order to see Domains and Application Areas and browse for objects contained in them. Definers also need View privileges on an object subtype in order to copy a definition of that subtype, and Create privileges for each object subtype on an Application Area in order to create a definition of that subtype in an Application Area.

Oracle LSH-Specific Roles

Oracle LSH-specific roles are useful for sensitive operations that only a few people should be allowed to do in Oracle LSH. You can assign these roles to users who also have more general roles assigned. For example, you may want to define the following roles:

Blind Break. A blind break is the execution of a report on real, sensitive data while it is still blinded—usually done for medical emergency reasons during the course of a trial. Create a Blind Break role specifically to allow creating a one-time blind break on patient data at runtime, and read the resulting report(s). This requires the Blind Break operation on both Table instances and on Outputs.
Unblind. Create an Unblind role to allow permanently unblinding Tables at the end of a study.

Note:
To perform a blind break or to permanently unblind data, a user must have a special application role as well as access to the particular object through a user group; see "Application Roles".
Librarian. Create a Librarian role with all operation privileges on all definitional object types, add the role only to user groups assigned to a Domain, and within those user groups assign the role only to the few Data Managers you want to be able to modify library definitions. (You can allow all definition-related roles, such as Programmers and Data Managers, to view all object definitions in the Domain library so that they can see, copy, and reference library definitions.)

Application Roles

In addition, Oracle LSH ships with a set of predefined roles that serve an entirely different purpose. Most of these application roles allow access to parts of the Oracle LSH user interface (UI) such as tabs and subtabs, and allow specific actions in those UI tabs and subtabs. You must assign at least one application role to each user account. See "User Interface Security" for further information, including a list of Oracle LSH's application roles.

User Groups

A user group definition consists of a name, description and a list of roles available to assign to users within the group. A user group also includes at least one group administrator, who adds users to the group and assigns them to roles within the group. The group administrator can also remove users from the group and remove roles from users within the group.

The security administrator creates users and user groups and assigns users to be group administrators, but cannot add or remove users from groups or assign him or herself as a group administrator.

To make user group creation easier, the security administrator can copy one user group definition, which includes the roles assigned to the group, to create another user group. It is possible to copy the assigned users as well. The group administrator can then add and delete users and change users' role assignments.

User groups determine which users have access to which objects. (The operations they can perform on an object depend on the roles they have within the user group that allows them access to the object.) To have access of any kind to an object, a user must belong to a user group that is assigned to the object. User groups can be assigned to an object either directly or indirectly by inheritance.

User group object assignments are not object version-specific. As an object is upgraded to one new version after another, the same user groups have access to it unless you explicitly usassign them. If you usassign a user group, its users can no longer see any version of the object.

To explicitly assign or unassign a user group to an object, or to revoke an inherited user group assignment, a user must have a role that allows the Manage Security operation on the object.

Explicit User Group Assignment to Objects

If you have the necessary privileges, you can explicitly assign a user group to any object, including containers, object definitions, object instances, Execution Setups, and outputs, at any time.

User Group Assignment by Inheritance

Objects inherit the user group assignments of their container object. You can explicitly revoke an inherited user group assignment for a particular object if necessary.

For example, if you assign a user group to a Domain, the system assigns that user group by default to all child objects as they are created: the child Domains in the Domain (if any), all the Application Areas in the Domain and in all of its child Domains, and all the object definitions and Work Areas in the Application Areas, all the object instances in the Work Areas, and all the execution setups and outputs of all the object instances. See Figure 4-2, "LSH Object Ownership" and Appendix B, "Object Ownership" to see these relationships displayed graphically.

Assignment revocations are also inherited. If you explicitly revoke the inherited user group assignment to a particular Application Area within the Domain, the user group is also no longer assigned to any of the object definitions or Work Areas contained in the Application Area.

Because user group assignments are inherited, in general it is best to create user groups with narrowly defined roles to assign to Domains. Assign users to roles with maximum privileges at the level where they will primarily work: for Definers, the Application Area (to allow creating object definitions through instances in the Work Area). Put Consumers in a user group assigned to the production Work Area so they can see and execute Execution Setups and outputs. See "Example of Security Design".

Figure 4-2 LSH Object Ownership

Description of ''Figure 4-2 LSH Object Ownership''

Note:

*Execution Setups, jobs and outputs are contained in instances of executable objects only—not in Table or Business Area instances.

Figure 4-2 shows the containers that constitute the organizational structure—Domains, Application Areas, and Work Areas—and the object definitions or instances they contain.

Duplicate Assignments

It is possible to assign the same user group to an object both implicitly (by inheritance) and explicitly. In that case, if either one of the assignments is removed, the user group is still assigned to the object because of the other assignment.

You can see all inherited and explicit assignments in the object's security screen.

Users

Enroll each person who will use Oracle LSH in any way by defining a user account for him or her. The user account includes a user ID, encrypted password, email address, and at least one application role.

Application roles allow the user to view a portion of the Oracle LSH user interface (UI) or to perform special operations; see "User Interface Security". A user's assigned application roles apply across all Oracle LSH Domains and objects; they are not associated with user groups.

Assigning Users to User Groups A person's assignments to user groups and the roles to which he or she is assigned within those groups determine which operations the person can perform on which objects; see "About Security Design in the Oracle Life Sciences Data Hub". A user can belong to any number of user groups, and can have any number of object security roles within a group. A user can have different roles in different user groups. A user must have at least one role within each group. The group administrator assigns users to groups and to roles within groups.

User Interface Security

Oracle LSH ships with predefined application roles that allow access to portions of the Oracle LSH user interface. Application roles apply to the user across the Oracle LSH application; they are not user group-specific. When you create a user account, you must assign it at least one application role so that the user can see at least part of the Oracle LSH user interface.

There are two types of user interface roles:

Application Roles allow users to work with Oracle LSH on an ongoing basis.
Administrator Roles are required for the initial setup of Oracle LSH. Some administration roles are also required for the ongoing maintenance of Oracle LSH.

Application Roles

Most Oracle LSH users need one or more of the predefined application roles to perform their work in Oracle LSH. The predefined Oracle LSH application roles are:

LSH Consumer Users assigned the LSH Consumer role have access to the Home and Reports tabs in the Oracle LSH user interface. Assign this role to users who need to retrieve information from Oracle LSH and/or run Oracle LSH applications to load and transform data. Oracle LSH object security determines which operations these users are allowed to perform on particular applications and reports.

LSH Definer Users assigned the LSH Definer role have access to the same tabs as the LSH Consumer plus the Applications tab. Assign this role to users who must build, test, or validate Oracle LSH applications. Oracle LSH object security determines which operations these users are allowed to perform on particular defined objects and outputs.

LSH Data Blind Break User Only the LSH Data Blind Admin can assign this role to users. This role does not provide access to any tabs in the Oracle LSH user interface. Users assigned to this role typically also have the LSH Consumer role.

Users with this application role can do the following, if they have normal Oracle LSH object security access and the blinding-related object security privilege noted:

Run a job on Tables with a Blinding Status of Blinded that displays the real data, not the dummy data (also requires an object security role with the Blind Break operation on Table instances)
View the output(s) generated by a job run on real, blinded data (also requires an object security role with the Blind Break operation on outputs)

LSH Data Unblind User Only the LSH Data Blind Admin can assign this role to users. This role does not provide access to any tabs in the Oracle LSH user interface. Users assigned to this role typically also have the LSH Consumer role.

Users with this application role can do the following, if they have normal Oracle LSH object security access and the blinding-related object security privilege noted:

Permanently unblind data in Table instances (also requires an object security role with the Unblind operation on Table instances)
Run a job on real data in Table instances whose status is Unblinded (also requires an object security role with the Read Unblind operation on Table instances)
Change the status of an output from Blinded to Unblinded (also requires an object security role with the Unblind operation on outputs)
Read outputs with a status of Unblinded (also requires an object security role with the Read Unblind operation on outputs)

Administrator Roles

To provide the most secure environment, the tasks required to set up Oracle LSH are logically grouped, and each group of tasks must be performed by a user with a different administrative application role.

The System Administrator role is automatically created during Oracle LSH installation. Your designated system administrator must log on using this account, create at least one user account and assign the LSH Setup Admin role to the account (or create at least two user accounts and assign the two Setup Admin component accounts—LSH Data Security Admin and LSH Function Security Admin—separately).

Figure 4-4 shows the flow of Oracle LSH security tasks.

Figure 4-3 Oracle LSH Security Adminstrator Tasks

Description of ''Figure 4-3 Oracle LSH Security Adminstrator Tasks''

The Oracle LSH Administrator roles are:

LSH Data Security Admin The LSH Data Security Administrator has access to the Security tab in the Oracle LSH user interface and works with user groups, subtypes, and roles to set up object-related security.

LSH Function Security Admin The LSH Function Security Administrator works in the Oracle Applications UMX user interface to register users (create user accounts) and assign application roles to them.

LSH Security Admin LSH Security Administrator is a predefined composite role that combines the functions of the LSH Data Security Admin and LSH Function Security Admin roles. To allow the same person to perform both functions, assign just the LSH Security Admin role.

LSH Classification Admin The LSH Classification Administrator has access to the Classifications tab in the Oracle LSH user interface and can create classification hierarchies and add terms to them.

LSH Data Blind Admin The LSH Data Blind Administrator can assign the LSH Data Blind Break User role and the LSH Data Unblind User role to users.

LSH Group Admin Every Oracle LSH user group must have at least one LSH Group Administrator. The Group Administrator can add and remove users from the user group and change users' role assignments within the group.

LSH Bootstrap Admin The LSH Bootstrap Administrator can create Domains and assign user groups to the Domains. This is the first step in creating an organizational structure.

LSH Super User The LSH Super User has access to all user interface tabs in LSH: Home, Applications, Reports, Classification, Security, and Administration, as well as the Oracle Applications user and role screens. The Super User role does not include the Bootstrap role or the blinding-related roles.

Security for Blinded Data

This section contains the following topics:

About Data Blinding, Blind Breaks, and Unblinding
Blinding-Related Security Privileges
Interaction of Blinding Statuses and User Privileges on Executing Jobs and Viewing Data

About Data Blinding, Blind Breaks, and Unblinding

Some sensitive clinical data must be protected from viewing during the course of a clinical trial; for example, treatment codes that would reveal which patients were receiving which drugs.

Oracle LSH supports data blinding in Oracle LSH Table instances and in all reports generated using one or more blinded Table instances as a source. Users with special privileges can unblind data (for example, at the end of a trial) or break the blind temporarily as required during the trial. Separate privileges are required to run and view reports generated on blinded and unblinded data.

All Table instances have a Blinding flag. You must set this flag to Yes to indicate that the Table instance may contain blinded data. If the Blinding flag is set to Yes, Oracle LSH maintains two sets of rows: one set for the real data and another set for dummy data, effectively partitioning the table in the database.

When a user loads data or runs a Program that reads from or writes to a Table instance whose Blinding flag is set to Yes, he or she must indicate in the submission form whether the job is running on real, blinded data or on dummy data. The system reads from and writes to the partition the user indicates. The options for the particular user submitting the job are limited by his or her own blinding-related security privileges; see "Blinding-Related Security Privileges".

Note:

Oracle LSH cannot ascertain whether data in an external system requires blinding or not. You must set up your security system so that only people who understand the issues and the source data can run Load Sets that may load sensitive data.

Table instances also have a Blinding Status attribute. Table instances whose Blinding flag is set to Yes can have a Blinding Status of either Blinded or Unblinded to indicate the current state of the data. Table instances whose Blinding flag is set to No can have a status of either Not Applicable (the default) or Authorized, which makes it possible for a nonblinded Table instance to be the target of a Program that reads from one or more blinded Table instances; see "Reading from Blinded Table Instances and Writing to Nonblinded Table Instances".

Oracle LSH allows you to keep data securely blinded and also allows the following:

Blind Break. A blind break is access to real, sensitive data that remains blinded to other users; it is a single execution of a job that reads from or writes to one or more blinded or unblinded Table instances. The Program may produce a report that displays the real, sensitive data. Even the log file of the job may contain sensitive information. One privilege is required to execute the job, and another privilege is required to view any resulting outputs. All blinded Table instances involved remain blinded and the same privilege is required to run the same executable again on the real data.

The Blind Break privilege also allows access to real, blinded data through the Browse Data feature, through an integrated development environment (IDE), and through data visualizations; see "Blinding-Related Security Privileges" below.
Unblind. Users with unblind privileges can permanently unblind data in a Table instance. They can also reblind the Table instance if necessary. A separate privilege is required to view reports generated on unblinded data.

For further details on how Oracle LSH handles blinded data, see "Execution and Data Handling" in the Oracle Life Sciences Data Hub Application Developer's Guide.

Blinding-Related Security Privileges

This section contains the following topics:

Blinding-Related Object Security Operations
Blinding-Related Application Roles

To perform most operations on sensitive data, a user must have normal security access to the particular Table instances or outputs that contain the sensitive data, a specific blinding-related operation on those objects, and a specific blinding-related application role.

Blinding-Related Object Security Operations

This section contains the following topics:

Operations on Table Instances
Operations on Outputs

To perform a blinding-related operation on a Table instance or output, a user must be assigned a role that includes the relevant object security operation on Table instances or outputs of the relevant subtype within a user group assigned to the particular Table instance or output.

Operations on Table Instances Oracle LSH has the following blinding-related object security operations on Table instances:

Blind Break allows access to real data in a Table instance whose Blinding Status is currently either Blinded or Unblinded as follows:
- If a user has Blind Break privileges on all blinded and unblinded Table instances that serve as a data source or target for a job, the user can run the job on real data to produce an output and/or write data to one or more target Table instances.
- If a user has Blind Break privileges on all blinded and unblinded Table instances in the underlying Business Area, the user can view real data when he or she launches a data visualization tool such as Oracle Business Intelligence Enterprise Edition.
- If a user has Blind Break privileges on a blinded or unblinded Table instance, the user can choose to view real data in the Table instance using the Browse Data feature.
- If a user has Blind Break privileges on all blinded and unblinded Table instances mapped to a Program instance, the user can choose to view real data when he or she launches an integrated development environment (IDE) such as SAS to work on the Program instance.
  
  Note:
  The functionality described in the last two points is intended for Definers, and users must also have the LSH Definer application role to see the Applications tab in the user interface and use these features.
Read Unblind allows access to real data in the Table instances in all the same situations as Blind Break above, but only if all the relevant Table instances have been unblinded.
Read Data allows access only to dummy data in the blinded and unblinded Table instances in all the same situations as Blind Break above.
Unblind allows the user to unblind and reblind Table instances.

Note:
Unblinding Table instances also requires the LSH Definer application role to see the Applications tab in the user interface.

Operations on Outputs Oracle LSH has the following blinding-related operations on outputs:

Blind Break allows viewing outputs with a status of Blind Break (whose data was generated from, or written to, one or more Table instances whose Blinding Status was Blinded or Unblinded at runtime).
Read Unblind allows viewing outputs with a status of Unblinded (whose data was generated from, or written to, one or more Table instances whose Blinding Status was Unblinded and no Table instances whose Blinding Status was Blinded at runtime).
Unblind is designed to allow unblinding outputs but has not been implemented in Oracle LSH Release 2.4.8.

Note:

In the Example of Security Design, roles allowing blinding-related operations are included only in the Production Work Area user group. Users assigned these roles can perform blinding-related operations on all Table instances and outputs in the Production Work Area.

If you want to restrict a user's unblinding privileges to a single Table instance, you must create a user group specifically for that Table instance with the necessary role and assign it to the few users who should have unblinding privileges on that Table instance.

Blinding-Related Application Roles

To perform blinding-related operations on Table instances or outputs, a user must have the relevant blinding-related application role in addition to the required blinding-related object security privilege.

While a user group administrator assigns blinding-related object security privileges to a user in the context of a particular user group, blinding-related application roles are assigned to users by a system administrator and apply across Oracle LSH; they are not limited to a particular user group, object subtype, or Domain, for example.

LSH Data Blind Break User A user must have the LSH Data Blind Break User application role in order to perform a Blind Break object security operation on Table instances or outputs; see "Blinding-Related Object Security Operations" .

LSH Data Unblind User A user must have the LSH Data Unblind User application role to either unblind or reblind Table instances. (No application role is required for the Read Unblind operation on either Table instances or outputs.)

Interaction of Blinding Statuses and User Privileges on Executing Jobs and Viewing Data

The interaction of Table instance and output Blinding Statuses and blinding-related user privileges is summarized in Table 4-1 and described in detail below. The information in the column Data Available to User applies to users who are running jobs, using the Browse Data feature on a single Table instance, launching a visualization, or working on a Program in an IDE.

The information in the rightmost columns applies only to outputs generated by running jobs on the source Table instances (not to Browse Data, visualizations, or IDEs).

Table 4-1 Summary of the Interaction of Blinding Statuses and User Privileges on Viewing Data

Most Restrictive Blinding Status of Any Source Table Instance	Most Powerful User Privilege on All Relevant Table Instances	Data Available to User	Resulting Output Blinding Status	User Privilege Required on Output to View Output
Blinded	Blind Break (and the LSH Data Blind Break User application role)	Dummy or Real	If real data processed: Blinded If dummy data processed: Dummy	If real data processed: Blind Break (and the LSH Data Blind Break User application role) If dummy data processed: View
Blinded	Read Data or Read Unblind	Dummy	Dummy	View
Unblinded	Blind Break (and the LSH Data Blind Break User application role) or Read Unblind	Dummy or Real	If real data processed: Unblinded If dummy data processed: Dummy	If real data processed: Read Unblind If dummy data processed: View
Unblinded	Read Data	Dummy	Dummy	View
Not Applicable	Read Data, Blind Break, or Read Unblind	Not Applicable	Not Applicable	View

The following sections describe the information summarized in the above table.

Blinded Table Instances If the user has the Blind Break operation on all blinded and unblinded source and target Table instances and the LSH Data Blind Break User application role, he or she can choose to run a job on—or view—either dummy or real data and:

Any output produced on real data has a Blinding Status of Blinded and the Blind Break operation on the output and the LSH Data Blind Break User application role are required to view the output.
Any output produced on dummy data has a Blinding Status of Dummy and the View operation on the output is required to view the output.

If any of the source or target Table instances whose Blinding flag is set to Yes has a Blinding Status of Blinded, and the user has only the Read Data or the Read Unblind operation on any of these Table instances, the user can run a job on—or view in an IDE— only dummy data. Any outputs produced have a Blinding Status of Dummy. The View operation on outputs is required to view them.

Unblinded Table Instances If all of the applicable Table instances whose Blinding flag is set to Yes have a Blinding Status of Unblinded, and the user has the Read Unblind operation on all the unblinded Table instances or the Blind Break operation on all the unblinded Table instances (and the LSH Data Blind Break User application role), the user can choose to run a job on—or view—real or dummy data.

Any output produced on real data has a Blinding Status of Unblinded and the Read Unblind operation on the output is required to view the output.
Any output produced on dummy data has a Blinding Status of Dummy and the View operation on the output is required to view the output.

If any of the applicable Table instances whose Blinding flag is set to Yes has a Blinding Status of Unlinded, and the user has only the Read Data operation on any of these blinded Table instances, the user can run a job on—or view in an IDE—only dummy data. Any outputs produced have a Blinding Status of Dummy. The View operation on outputs is required to view them.

Nonblinded Table Instances If all the applicable Table instances have their Blinding flag set to No and their Blinding Status is Not Applicable, the Table instances contain real data that is not sensitive and does not required blinding. The user requires only the Read Data operation on the Table instances to run a job on—or view—the data. Any output produced has a Blinding Status of Not Applicable, and the View operation on the output is required to view the output.

Reading from Blinded Table Instances and Writing to Nonblinded Table Instances In rare cases you may need to run a Program that reads from one or more blinded or unblinded Table instances and writes to one or more nonblinded Table instances (whose Blinding flag is set to No). Executing such a job fails unless:

Every target Table instance whose Blinding flag is set to No has a Blinding Status of Authorized.
The user running the Program has Blind Break privileges on all blinded source and target Table instances and either Blind Break or Unblind privileges on all unblinded source and target Table instances.
The user running the Program explicitly authorizes running the Program after a warning that the Program reads from one or more blinded or unblinded Table instances and writes to one or more nonblinded Table instances.

Example of Security Design

In this example, pictured below, are the following Domains:

One Domain for each drug project. Inside each project Domain is a library of standard definitions for use within that project, an Application Area for each study, plus another Application Area for projectwide analysis. Within each Application Area are three Work Areas, one each for development, quality control, and production.
One Domain for companywide reports with two Application Areas: one Application Area for the report listing all investigators and another for companywide enrollment reports. A Domain library contains the standard companywide report definitions
One Domain for a library of standard company definitions.

In general, there is a user group defined for each organizational structure (Domain, Application Area, and Work Area). See "Example User Groups".

Figure 4-4 Organizational Structure for Security Design Example

Description of ''Figure 4-4 Organizational Structure for Security Design Example''

Example User Groups

Following is information on each user group used in this example, including a list of the roles assigned to each.

Project 123 Domain User Group

The Project 123 user group is assigned to the Domain that includes all of Project 123.

The privileges granted to a user through his or her role(s) in a user group assigned to a Domain apply by default to the Application Areas and Work Areas in the Domain, unless the user group is explicitly unassigned from a particular container.

Therefore, the roles assigned to the Domain user group should allow only the operations required to allow the proper use of the object definitions in the Domain library. See "Domain Libraries" for a discussion of the recommended usage of Domain Libraries.

The Project 123 user group includes the following two roles:

Librarian/Project Programmer. The Librarian (or Project Programmer) role allows maintenance—including creation, modification, and deletion— of the object definitions of all types in the Domain library. The Create operation is required to move an object into the library.

We recommend that these definitions be developed in the Domain's Application Areas and moved into the library only after they are stable, validated, and approved for reuse. They should then need very little maintenance. Assign this role to only a few people.
View All Definitions. All Programmers and Data Managers working on Project 123 need the View operation on all object definitions in the Project 123 Domain library so that they can reuse those definitions. Therefore, all users who have the Programmer or Data Manager role for any study in the Project 123 Domain also belong to this user group with the role View All Definitions.

Study 123ABC Development User Group

The Study 123ABC user group is assigned to the Study 123ABC Application Area.

Programmers work on object instances in a Work Area, but when they create a new object, Oracle LSH automatically simultaneously puts the new object definition in the Application Area that contains the Work Area, and an instance of it in the Work Area. Therefore, to be able to develop new object definitions for a study, Programmers need Create and Modify privileges on object definitions in the Application Area as well as on object instances in the Work Area. They also need View privileges on each object subtype.

Note:

If you develop a set of standard modular object definitions, you may be able to develop applications entirely by reusing those definitions. In that case, some users may require only Create, Modify, and Delete privileges on object instances in the Development Work Area and View privileges in the library of standard definitions.

The privileges granted to a user through his or her role(s) in a user group assigned to an Application Area apply by default to all the Work Areas in the Application Area, unless the user group is explicitly unassigned from a Work Area.

In this example this user group is explicitly unassigned from the Quality Control and Production Work Areas so that Definers cannot modify on objects in those Work Areas. Definers work in the Development Work Area only. See "Work Area Usage Intent and Validation Status".

The Study 123ABC user group includes the following roles:

Programmer The Programmer role allows all the creation of all object definition types in an Application Area and modification operations on object definitions and instances of all types, including Modify Validation Status QC. The Programmer role has these same privileges on object instances types in a Work Area. The Programmer can therefore create new object definitions and instances or create new instances of existing definitions, test them, and promote them to Quality Control after successful testing.

Data Manager The Data Manager role allows the same operations as the Programmer role, but has Modify Validation Status Production (instead of QC), which allows promotion to both QC and Production. In addition, a Data Manager can clone Work Areas. For this, the Data Manager must have the Modify rights on Work Areas as well as Clone.

Study 123ABC Quality Control User Group

The Study 123ABC Quality Control user group is assigned to the Quality Control Work Area in the Study 123ABC Application Area. Its purpose is to allow Quality Control engineers to test applications but not to modify objects.

Quality Control Engineer The Quality Control role allows the View operation on object instances of all types, and the Submit operation on object instances of all executable object types. Therefore Quality Control engineers can run all executable objects in any Work Area in the Application Area and view the resulting outputs, but they cannot modify any objects.

Data Manager The Data Manager role allows all operations on all object types. Because this user group is assigned to a Work Area, only the operations on object instances are relevant. The Data Manager can modify object instances so that they point to the new version of a fixed object. The Data Manager has the IQ_Submit role needed to run executables to test them before promoting object instances to the Quality Control validation status. The Data Manager can also clone the Work Area.

See "Work Area Usage Intent and Validation Status" for information on the intended usage of Work Areas and the interaction of objects' validation status and the Work Area Usage Intent attribute.

Note:

In this example, the Study 123ABC user group is explicitly unassigned from the Quality Control Work Area so that Programmers cannot change object instances in the QC environment. Programmers should make any necessary changes in the Development Work Area, and then the Data Manager should clone the modified Work Area onto the Quality Control Work Area for testing.

Alternatively, if your operating procedure is for your Definers to test their own applications, you do not need the Quality Control user group. To allow programmers and data managers full privileges on the Quality Control Work Area, simply do not unassign the Development user group from it.

Study 123ABC Production User Group

The Study 123ABC Productionuser group is assigned to the Study 123ABC Production Work Area. The Production Work Area controls security access to the Oracle LSH schema that contains production data and outputs on production data. Therefore all personnel who need to see reports on production data need access to the Production Work Area.

This is the first user group in this example to differentiate between privileges on one subtype and another. In this security system, Programmers, Data Managers, and Quality Control Engineers can work on objects of any subtype; for example, Financial or Clinical Report Sets. However, the Production Work Area user group includes users who can see only Clinical object subtypes, users who can see only Financial object subtypes, and some users who can see both subtypes.

Note:

In this example, the Study 123ABC Development user group is explicitly unassigned from the Production Work Area so that Programmers cannot change object instances in the production environment.

Some of the roles listed here have the same privileges on the same object types. From the point of view of Oracle LSH, a single role could be substituted for these. However, it may be easier to administer user accounts if you create roles for actual job titles in use in your company and assign them to the people who hold those jobs.

The following roles have Submit and View privileges on instances of Programs, Report Sets, Workflows, and Business Areas (for data visualizations). They also have the Read Data operation on Table instances so they can run executables on Table instances, and the View operation on outputs.

Most roles should include

Investigator. Has operations on subtype Clinical Programs, Report Sets, Workflows, and Business Areas only.
Statistician. Has operations on subtype Clinical Programs, Report Sets, Workflows, and Business Areas only.
Project Manager. Has operations on both subtypes: Clinical and Financial Programs, Report Sets, Workflows, and Business Areas.
Blind Break Manager. Has operations on subtype Clinical Programs, Report Sets, Workflows, and Business Areas only.

The following roles have Submit and View privileges on Execution Setups of Load Sets and Data Marts in addition to Programs, Report Sets, Workflows, and Business Areas:

Trial Manager. Has operations on both subtypes, Clinical and Financial, for each object type.
Submission Officer. Has operations on only the Clinical subtype of each object type.

Three additional roles allow certain operations on blinded data. By creating a separate role for this purpose, you can limit this sensitive privilege to the minimum number of people required to perform it in your organization. You can assign these roles to users who also have other roles. See "Security for Blinded Data".

Note:

These roles are different from the LSH Data Blink Break User application role and the LSH Data Unblind User application role. One of those application roles is required in addition to these object-specific roles to create a blind break or unblind data. See Table 4-1, "Summary of the Interaction of Blinding Statuses and User Privileges on Viewing Data".

In addition, the user must be assigned to one of these roles in a user group with access to the object.

Blind Break. The Blind Break role includes the Blind Break operation on Table instances and on outputs. The Blind Break role allows a user to run a Program or other executable on a Table instance with a Blinding Status of Blinded and view the resulting outputs (see "Security for Blinded Data").
Permanently Unblind. The Permanently Unblind role includes the Unblind operation on both Table instances and outputs. The Unblind operation allows the user to change the Blinding Status of the Table instance or output from Blinded to Unblinded.
View Unblinded Data. The View Unblinded Data role includes the Read Unblind operation on both Table instances and outputs. Even after a Table or output has been permanently unblinded, this role is required to see the unblinded data.

User Groups for the Other Domains, Application Areas, and Work Areas

You may be able to use the user groups described in this example as standard user groups for all Domains, Application Areas, Quality Control Work Areas and Production Work Areas. Even the users in the user groups may be the same in some cases—especially in groups intended for Programmers and Data Managers.

You can copy user group definitions in two ways:

Copy just the definition, including the name, description, and assigned roles.
Copy all of the above plus all the users assigned to the user group, with their role assignments.

For example, the same simple, two-role Domain user group structure may be appropriate for all your Domains. In this case, you have the following choices:

If exactly the same people should have access to two Domains, with the same roles in each Domain, you can assign the same user group to both Domains.
If most of the same people should have access to two Domains, with the same roles in each Domain, you can copy the first Domain user group you create, including the users assigned to the group. You assign it to the second Domain and the Group Administrator can then make any necessary changes to users and users' role assignments.
If different people should have access to two Domains, you can copy the first Domain user group you create, using the option to not include any of the users. You can assign it to the second Domain. The Group Administrator then assigns users to roles within the group.

If the user group definition itself needs to be different from other Domains, you can define an entirely new user group or copy an existing one and make any necessary changes.

Example Users

In this example, you might have the following users:

Karl Martin. Karl is a programmer who works on both studies in Project 123. He is assigned to the following user groups: Project 123 Domain user group, Study 123ABC Development user group, and Study 123DEF Development user group.

In the Domain user group he has the View All Definitions role. In the two study user groups he has the Programmer role.
Sylvia Green. Sylvia is the data manager for Project 123. She is assigned to the following user groups: Project 123 Domain user group, Study 123ABC Development user group, Study 123ABC Quality Control user group, Study 123ABC Production user group, Study 123DEF Development user group, Study 123DEF Quality Control user group, Study 123DEF Production user group.

In the Project 123 Domain user group she has the Librarian role. In the other user groups she has the Data Manager role.
Sanjay Rao. Sanjay is a statistician working on both Project 123 and Project 456. He is assigned to the Production Work Area user group for all studies in Project 123 and all studies in Project 456.

In each user group he has the Statistician role, allowing him to see and execute Clinical Programs, Report Sets, Workflows, and Business Areas. He also has the Permanently Unblind role and the LSH Data Unblind User application role, allowing him to permanently unblind study data and view the results.
Sining Chen. Sining is an investigator for Study 123ABC. He is assigned to the Study 123ABC Production Work Area user group with the Investigator and Data Blind Break roles.

He can see reports and create data visualizations for Study 123ABC and create a Blind Break during the trial if necessary.

Design Decision Summary

To design a security system, you must complete the following tasks:

Design an Organizational Structure
Design a Set of User Groups
(Optional) Design One or More Object Subtypes
Design a Set of Roles and their User Group Assignments

Design an Organizational Structure

Take advantage of the fact that user group assignments are inherited by objects from their container. Design an organizational structure of Domains, Application Areas, and Work Areas where you can use this feature and avoid excessive manual assignments of user groups to containers and objects.

Restrictions None.

You can define any organizational structure you choose; see Chapter 3, "Designing an Organizational Structure".

Considerations Take the following into consideration:

You will assign user groups to the container objects in your organizational structure, so design an organization that reflects the logical units that the same group of users need to access.
You can explicitly unassign and reassign user groups to containers and other objects at any time.

Design a Set of User Groups

Design a set of user groups in conjunction with your organizational structure design.

See "User Groups" for further information.

Restrictions None.

You can define any number of user groups. You can assign any number of roles to user groups.

Considerations Take the following into consideration:

By default, all objects are automatically assigned the same user groups as their containing object.
You can explicitly unassign and reassign user groups to objects at any time.

(Optional) Design One or More Object Subtypes

Oracle LSH ships with a set of predefined primary object types, including definitions and instances of Tables, Programs, Load Sets, Report Sets, Data Marts, Workflows, and Business Areas. Oracle LSH also ships with one predefined subtype for each of these object types.

A role consists of a set of allowed operations on object subtypes. If you define additional subtypes for an object type, you can allow different roles to have operations allowed on different subtypes. For example, you might want different people to be able to view clinical reports and financial reports, in which case you can create Clinical and Financial Report Set Output subtypes.

See "Object Subtypes" for further information.

Restrictions None.

You can define any number of subtypes for any primary object type.

Considerations Take the following into consideration:

Use subtypes for broad categories of information separate from the logical categories you use for your organizational structure and user groups, but which also differentiate which users should have access to which objects. For example, if your organizational structure and user groups use Project and Study as their primary logical units, you could define subtypes of Clinical, Financial, and Administrative, which apply to all projects and studies.
If you are using Oracle LSH only for clinical data, you probably do not need additional subtypes. If you decide to use Oracle LSH for other types of data in the future, you can add subtypes then.
Objects inherit the subtype of their container object, if a subtype with the same name is defined for their own object type. Objects can also inherit classifications from their container objects, if you choose. To make object creation simpler, create a subtype with the same name for all object types, or at least all container and primary objects (Domains, Application Areas, Work Areas, Programs, Tables, Load Sets, Report Sets, Data Marts, and Business Areas). See "Design Decision Summary" in Chapter 5, "Designing a Classification System for Searching and Browsing" for additional considerations.

Design a Set of Roles and their User Group Assignments

A role definition consists of a name, description, and a set of allowed operations on one or more object subtypes. You assign roles to user groups and users to roles within user groups. A single user can have any number of roles, and can have different roles in different user groups.

See "Roles" for further information.

Restrictions None.

You can define any number of roles with any number of operations on object subtypes assigned to each role.

Considerations Take the following into consideration:

To simplify assigning users to roles, create roles that correspond to the actual jobs in your company.
You may want to create a few roles specifically to do certain Oracle LSH tasks, especially blinding-related tasks. You can then assign just a few users to those roles to keep blinded data as secure as possible.