This chapter describes how security is incorporated in many aspects of the Oracle Fusion Middleware (EDQ) architecture.
This chapter includes the following sections:
The security of communication between the web application server and the client applications is determined by the configuration of the Java Application Server hosting EDQ. The Java Application Server can be configured to use either HTTP or HTTPS.
EDQ authenticates user passwords against values held in the database repository or in a Lightweight Directory Access Protocol (LDAP)-enabled user management server. The passwords are held in a hashed form that the application cannot reverse. This configuration is used by:
the client user applications
the EDQ web pages
The client user applications authenticate users using a proprietary protocol over HTTP or HTTPS. Passwords are encrypted before being sent to the server.
The web pages are secured using forms-based authentication that communicates with the server over HTTP or HTTPS.
Mandatory password strength enforcement can also be configured, encompassing the following criteria:
Minimum length.
Minimum number of non-alphabetic characters.
Minimum number of numeric characters.
Prevention of recent password re-use.
Prevention of using the user name in the password.
Account security encompassing the following criteria can also be configured:
Password expiry.
Application behavior following failed login attempts.
EDQ stores security information in a number of places, depending on the nature of the information
Connection details for databases that EDQ connects to in order to perform snapshots and dynamic value lookups are stored in the configuration schema in the repository. This includes user names, passwords, hosts names, and port numbers for the database connections.
Passwords are stored in an encrypted form in the configuration schema or in a security store on WebLogic platforms, and then they are decrypted by EDQ when it needs to log into a database. A decrypted password is not shown to EDQ users or administrators.
The encryption/decryption key for passwords is generated randomly for each installation of EDQ. On WebLogic platforms, the key is retained in the security store. On Tomcat platforms, it is stored in a file in the EDQ configuration directory. This random key generation on a per-installation basis ensures that encrypted passwords cannot be copied meaningfully between systems.
In installations where EDQ uses Java Naming and Directory Interface (JNDI) connections to connect to the repository database, the authentication details to the database are stored in the application server. EDQ uses the credentials by referencing the JNDI names in a file (director.properties) in the EDQ base configuration directory (oedq_home).
When EDQ is being used across multiple business lines, or when several businesses are using the same system, it is important to be able to segment user access to data. EDQ supports this segmentation by allowing users and projects to be allocated to groups. Users can only access a project if they are members of the same group as the project. The Director user application presents accessible projects to a given user, and all other projects are invisible. The contents of any project (including reference data and web services) are unavailable to unauthorized users.
Note:
Since administrative users must be able to manage all the projects in the system, any user with permission to create projects can see all projects in the system regardless of project settings.