| Agile Product Lifecycle Management Security Guide Release 9.3.6 E71146-07 |
|
 Previous |
 Next |
This chapter describes how Agile PLM uses the following security features to provide data protection:
Authentication - allows only permitted individuals to get access to the system and data.
Access Control (Authorization) - provides authorized individuals access control to system privileges and data.
Audit - allows Administrators to detect attempted breaches of authorization and attempted (or successful) breaches of access control.
A password policy is a set of rules dictating how to use passwords. Some of the rules a password policy sets are:
The maximum length of time a password is valid
The minimum number of characters in a password
Password policies play an important role when attempting to access a directory. The directory server ensures that the entered password adheres to the password policy.
Agile PLM supports the Lightweight Directory Access Protocol (LDAP), Single Sign-On (SSO), and database authentication configurations.
The three supported authentication configurations are discussed below.
LDAP is an application protocol for querying and modifying directory services running over TCP/IP.
Agile PLM supports LDAP authentication through the Agile Directory Server Integration Module. You can integrate Agile with your existing directory server to manage your users in one place. This approach can be fully integrated into Agile PLM, for these supported directory servers:
Oracle Internet Directory Server
Microsoft Active Directory Server
Sun Java System Directory Server
Oracle Virtual Directory
If you chose to manage your user accounts through a directory server (instead of the database) during installation, then all new users are added, and certain user attributes are configured, only through the directory server. Users need to be synced from the LDAP system to the Agile PLM database.
For more information, refer to the "LDAP" chapter in the Agile PLM Administrator Guide.
Agile PLM can be integrated with various Single Sign-On (SSO) solutions. SSO is a web-based authentication solution and thus can be enabled for and used in the web client only.
Single Sign-On enables centralized security management including management of user credentials and access policies and can reduce the frequency and circumstances that the user is challenged for their credentials. When Agile PLM is configured for Single Sign-On, a user that has already been authenticated with the system (for example, with the operating system or a corporate portal) may not be prompted again for their credentials by the application.
Agile PLM is certified with the following Single Sign-On solutions:
SAML 2.0 SSO (SAML2) with Oracle IDCS as Identity Provider - may also work with other identity providers
Oracle Access Manager (OAM)
Microsoft Windows NT LAN Manager (NTLM)
For details on configuring Agile PLM with the above SSO solutions, refer to Appendix A of the Agile PLM Administrator Guide entitled "Configuring Single Sign-On".
|
Note: With some SSO solutions, PX/SDK applications, web service calls and AgileDrive (aka WebDAV) may not be able to connect to an Agile PLM application URL protected by SSO. In this case, calls must be made to an alternative entry point that is not protected by SSO. |
Customers can use Process Extensions (PXs) to extend the Agile PLM user interface or business logic. Agile PLM provides a process for the PX to access the Agile PLM server without having to explicitly provide credentials by passing a one-time-use encrypted authentication token to the application. The token is secured by storing it in the Agile PLM Database so that it is not accessible outside the application. This token can be used to ensure that a given instance of the PX call is valid and is executed only once after the PX has been executed by the user. Once the validation has been successful, the token is deleted before providing Agile PLM server access to the PX. Finally, the token itself expires after a certain time interval and this expiration time is configurable. Oracle recommends that this interval be configured to minimize potential misuse.
Authorization primarily includes two processes:
Permitting only certain users to access, process, or alter data.
Applying varying limitations on user access or actions. The limitations placed on (or removed from) users can apply to objects, such as schemas, tables, or rows; or to resources, such as time (CPU, connect, or idle times).
Before creating a new Agile PLM user, make sure you answer the following questions:
What does this user need to be able to do in Agile PLM? What default roles are required for this user?
What should this user be prevented from doing in Agile PLM?
Will this user need to have separate Login and Approval passwords?
On which Agile PLM lists will the user's name appear?
Which Agile PLM searches should the user be able to use?
Is the user a Power User? A Power User can log in at any time and is not counted as a member of the concurrent user pool.
Do not assign too many users and designated escalation persons to user groups. Only assign users based on the requirements of each user group. Update user groups regularly.
For more information about access control using roles and privileges, see the Agile PLM Administrator Guide. Refer to the following relevant sections:
Overview of Roles and Privileges in Agile PLM
Guidelines for Working with Roles
Securing and Maintaining Roles and Privilege Masks
Agile PLM enables you to audit your system by utilizing the User Monitor window, and through the data collected in an object's History Tab.
The User Monitor window lists the users that are presently logged in to the Agile PLM system. It displays the following information about each logged-in user.
| Table column | Description |
|---|---|
| User Name | The first and last name of the logged in user. |
| User ID | The login username of the user. |
| Host | Indicates the user's host. |
| Login Time | The time the user logged in. |
For more information, see the "User Monitor" section in the Agile PLM Administrator Guide.
The History tab shows a summary of actions taken against an object. History is recorded for all objects in your Agile PLM system's database, and shows all actions by users and administrators. The History tab gets automatically populated.
The types of actions recorded for items are:
Creation of the item
Attachment actions: view, open, add, delete, get, check in, check out, cancel checkout, incorporate, unincorporate, and field modifications on the Attachments tab.
Save As
Send
Modification of the subclass or any field of a released item
Subscription modification and sharing
For more information see:
Getting Started with Agile PLM
”History Tab” in the Agile Product Lifecycle Management Product Collaboration User Guide
An additional source of audit information is the set of log files. You can enable logging controls in Agile or in the WebLogic Server so that you can get more security-related information.
For more information about enabling logging, refer to the section "Logging Configuration" in the Agile PLM Administrator Guide.
For more information about enabling logging scripts in WebLogic, see ”Application Logging and WebLogic Logging Services” in the WebLogic Server documentation.
