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 has the possibility of integrating aspects of your PLM system with Single Sign-On (SSO) capability. SSO is a Web-based solution that can be enabled only for Agile Web Client.
Single Sign-On integrates with the centralized security management system, other business and training applications, and improves user productivity in the Agile Web Client environment. With SSO configured and enabled for your PLM system, a user that has signed in to the system once (for instance, through the corporate portal) is not prompted again by a "login" dialog.
Agile PLM is certified on the following Single Sign-On solutions:
Oracle Access Manager (OAM) - The secure configuration practices to configure Agile PLM with OAM Server can be found here: http://fusionsecurity.blogspot.co.uk/2010/04/security-clarification-oam-identity.html.
NT LAN Manager (NTLM)
Note the following:
Agile SDK code cannot connect to an Agile application URL protected by SSO.
Users cannot develop Java Web Service client code and connect to an Agile Web Service protected by SSO.
Webdav (AgileDrive) cannot connect to an Agile Application Server URL protected by SSO.
Web Service clients or SDK code must connect directly to Agile server nodes with actual WebLogic ports or set up an alternate proxy that is not protected by SSO.
For more information, refer to the "Configuring Single Sign-On" chapter in the Agile PLM Administrator Guide. The chapter also includes a helpful diagram of the Agile SSO Plug-in Architecture.
URL PX-based SSO
Customers use Process Extensions (PX) to extend Agile UI or business logic. Agile PLM has an SSO mechanism that allows the PX to access the Agile server without the user having to re-authenticate. Agile passes encrypted SSO tokens that the PX then submits back to the Agile server. This token is a one-time token. Additionally, the token is secure as it is stored in the Agile Database and not accessible. This token is used to ensure that the SSO mechanism will be valid only once after the UI PX has been clicked by the user. Once the validation has been successful, the token will be removed from the secure place before providing the Agile server access to the PX. Finally, the token itself expires after a certain interval. The expiration time is configurable and Oracle recommends that customers keep this interval to a very small value to prevent misuse of this token.
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 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.