3 Security features

In this chapter:

• User security features
  
• Application security features
  
• Data security features
  

User security features

In this section:

• Password configuration for user security
  
• Passwords for new users
  
• Login security
  
• No data loss after a session transaction
  
• Automatically deactivated user accounts
  
• Restricted access to the application
  
• Security events logs
  

Password configuration for user security

An administrator can define the following formatting, entry, and reuse requirements for passwords in the Oracle Health Sciences Central Designer Administrator software. For the recommended settings, see General security principles and the Administration Guide.

• Number of days before the password expires. Maximum recommended setting is 90 days.
• Number of recently used passwords that are remembered in the system and cannot be reused. Minimum recommended setting is four passwords.
• Minimum length of the password. Minimum recommended setting is eight characters.
• Number of login attempts allowed. Maximum recommended setting is three.
• Password complexity. Recommended setting is High.
• Amount of time that a user is locked out after exceeding the allowed number of login attempts. Recommended setting for the system and user accounts is 30 minutes.
• Length of time a user can be inactive before session timeout. Recommended setting is 20 minutes.
• Amount of time before a user must reauthenticate during a session. Recommended setting is four hours.

Passwords for new users

When you create new users, the users should change their passwords the next time they log in.

Login security

Users must enter their user names and passwords to log in. The application does not allow duplicate user names.

If either a user name or password is incorrect, an error message appears, but does not tell the user the value that is incorrect. Therefore, if someone else is using the account to attempt to log in, the message does not confirm either a user name or password.

No data loss after a session transaction

The Oracle Health Sciences Central Designer application is configured to require users to re-enter their user names and passwords after a defined period of inactivity. The user can log in and continue working in the application without losing data.

This security feature is controlled by the following settings in the Oracle Health Sciences Central Designer Administrator application:

• Inactivity timeout —Number of minutes of inactivity that can pass before the Oracle Health Sciences Central Designer application requires a user to log in again.
• User must re-authenticate every —Number of minutes that a session can be active before the Oracle Health Sciences Central Designer application requires a user to log in again.

Select values for these settings that work with your studies.

Automatically deactivated user accounts

The Oracle Health Sciences Central Designer application is configured to allow a defined number of attempts to log in correctly. When a user exceeds the number of allowed login attempts, which is defined in the Oracle Health Sciences Central Designer Administrator application, the user account is inactivated and the user cannot log in.

Only a user with the appropriate rights can activate an automatically inactivated account. Relevant rights include:

• Activate users.
• Terminate and deactivate users.

Restricted access to the application

You can restrict access to the application in the following ways.

• Terminate a user.

  Typically, you terminate users who leave the organization. Terminated users cannot log in to the application. All users, including terminated users, remain in the study for audit purposes. A terminated user can never be activated or deactivated. If you terminate a user account, you can never use the account again.

• Deactivate a user.

  Typically, a user is automatically deactivated when the user fails to log in after the number of attempts set in the Oracle Health Sciences Central Designer Administrator software. After the user account is deactivated only an administrator can manually reactivate the user. The user must be reactivated before the user can work in the application.

Security events logs

The Oracle Health Sciences Central Designer application is configured to log the following security events:

• Successful logins.
• Failed logins.
• Password changes.
• Unauthorized access attempts.
• Unexpected failed validations of SAML tokens (indicating attempted bypass of validation).
• Changes to password management policies.

The following information is logged for every security event:

• Date and time.
• IP address.
• User name.
• Computer name.
• Event message, where applicable.

The data is captured in the PM_AUDIT_EVENT table. Because this table might grow rapidly over time, make sure to periodically export it, and then either truncate the table, or delete older rows.

Application security features

In this section:

• Rights assigned to roles
  
• Users assigned to roles
  
• Default user
  

Rights assigned to roles

A right is the permission to perform a specific activity. A role can have a library, study, or application scope. Each scope has a set of rights that you can grant to the role.

Rights grant access to different parts of the Oracle Health Sciences Central Designer and Oracle Health Sciences Central Designer Administrator applications. Entire parts of the application are hidden when users do not have the rights to work in those areas.

When a new user is created in the Oracle Health Sciences Central Designer application, an administrator with the right to modify user information assigns the user to a role in the library, study, or application scope, providing the user permissions to perform specific activities.

For example, a user can be assigned to the Study Collaboration role, which contains the right to create and assign tasks. The individual create and assign tasks right is static, but the group of rights assigned to the Study Collaboration role are configurable.

For more information, see the Administration Guide.

Users assigned to roles

After you review the rights that are assigned to roles and make any necessary changes, you can assign users to roles. A user assigned to a role has the rights that are granted to that role. Changes to a role are immediately applied to all users assigned to the role.

In addition, for each library and study role, a corresponding team exists. When you assign a user to a role, the user is also assigned to the team for that role. To assign a user to a team associated with a role, you rust first assign the user to the role.

A user can be assigned to a role that has one of the following scopes:

• Library —A user assigned to a library role is granted the rights associated with the role only in libraries where that user is also a member of the library team for the role.
• Study —A user assigned to a study role is granted the rights associated with the role only in studies where the user is also a member of the study team for the role.
• Application —A user assigned to an application role is granted all of the rights that are associated with the role, without restrictions.

You can also grant users the rights to perform administrative tasks such as configuring users, roles, rights, and system configuration settings. Administration users can also have unlimited rights in the Oracle Health Sciences Central Designer application. Ensure that you limit the users who have administration rights. For a description of administration rights, see the Administration Guide.

Default user

The Oracle Health Sciences Central Designer application installs the system user by default. During the installation, you configure a password for this user. In addition, you can configure the lockout time for the system user separately from all other users. By default, this user is assigned the superuser and DesignerAdministrator roles.

Oracle recommends that you create administrator accounts for individual users, and delete the system user after the initial application configuration.

Data security features

In this section:

• Protecting study objects
  
• Audit trails for data security
  

Protecting study objects

You can protect a library or a study to prevent users from making changes to study objects that you do not want to be modified.

When you protect a study or library, changes cannot be made to study objects or to the structure of the study or library.

When a study object is protected, its icon changes to reflect its protected state.

For more information, see the Administration Guide.

Audit trails for data security

Audit trails are comprehensive records that include information about each change that occurs in the Oracle Health Sciences Central Designer application.

The audit trail for the Oracle Health Sciences Central Designer application records each change, and for each change:

• Person who made the change.
• Date and time of the change.

You cannot modify data in an audit trail. For more information, see the User Guide.