3 User Authentication

This chapter explains how users are authenticated in EDQ.

This chapter includes the following sections:

3.1 The EDQ login.properties File

User authentication in EDQ is configured using a file named security/login.properties in the EDQ configuration area. The file may exist in either the 'home' configuration directory or the 'local' configuration directory, or both. If present in both, the settings are merged with the values in the 'local' directory taking precedence. If you need to make changes to the file, always edit a version in the 'local' directory.

The EDQ 'home' configuration area contains a file security/login.properties.template which contains example settings for several types of LDAP integration.

The login.properties file defines a number of 'realms'. Each realm is an independent store of users. The file will start with global settings, followed by settings for each realm. Standard global settings are:

realms = realm1, realm2, …
gss    = false

The realms property defines the list of realms configured in this installation. The names are arbitrary, except that the special realm name 'internal' specifies the EDQ internal user store (user dnadmin etc).

The 'gss' setting turns off advanced Kerberos style authentication.

The global settings are followed by blocks of realm specific properties, each prefixed with the realm name from the global list. For example, a configuration which uses the internal realm and an LDAP realm could be:

realms                                = internal, corpldap
gss                  = false
corpldap.realm       = EXAMPLE.COM
corpldap.ldap.server = dc1.example.com

These settings are covered in more detail below.

If more than one realm is defined in login.properties, the EDQ login screens - web console and UIs - will contain a dropdown selector for the realm associated with the username and password.

3.1.1 Static Groups Mapping in login.properties

If you are using an external LDAP user store, and do not wish to use the EDQ internal user store, then you will face a bootstrapping problem when attempting to setup mappings from LDAP groups to EDQ groups. This is done using the EDQ web console and requires an EDQ administrator login. However a LDAP group mapping to the EDQ Administrators group is required before an LDAP user can login to EDQ.

To overcome this problem you can define static group mappings in login.properties. The syntax is:

realm.xgmap = exgroup1 -> edqgroup1, exgroup2 -> edqgroup2 …

'realm' is the realm name as listed in the global realms list. Each 'exgroup' is the name of an external LDAP group; each 'edqgroup' is the name of an EDQ group.

Static mappings should be used only to set the initial Administration mapping; other mappings should be configured in the EDQ web console External Groups page.

For example, to map an LDAP group named 'EDQ-ADMINS' to the EDQ Administrators group, add:

corpldap.xgmap = EDQ-ADMINS -> Administrators

3.2 WebLogic Installations

A standard installation of EDQ on WebLogic will use the domain's internal user store for authentication. This contains the domain administration user (usually 'weblogic') and a small set of other users.

The EDQ default security configuration maps any user in the WebLogic Administrators group to the EDQ Administrators group. No other group mapping are defined initially.

To add more users, login to the WebLogic administration console, and navigate to the Users and Groups tab in the default security realm.

Surrounding text describes weblogic_install_sec_3.2.png.

As an alternative to managing users in WebLogic you can integrate with an external source of users, normally an LDAP server, such as Active Directory. Integration can be configured in the WebLogic administration console or directly from EDQ by editing the security configuration file. The former approach is covered in Chapter 4, "Integrating External User Management (LDAP) using WebLogic and OPSS" and the latter in Chapter 5, "Configuring External User Management (LDAP) directly with EDQ".

The default login.properties in the 'home' configuration directory contains:

realms     = opss
opss.realm = ORACLE
opss.label = Weblogic
opss.type  = opss
opss.xgmap = Administrators -> Administrators

This configuration indicates that the OPSS library supplied by WebLogic is used for authentication and that the WebLogic Administrators group is mapped to the EDQ Administrators group.

3.3 Enabling the internal realm

To manage users internally, the internal realm needs to be enabled. Follow the procedure below to enable the internal realm for users:

  1. Create a subdirectory called security in the local configuration directory (oedq_local_home/security).

  2. Copy the login.properties file from the security directory of the base configuration directory (oedq_home/security) to oedq_local_home/security.

  3. Add 'internal' to the comma-separated list of realms.

    Note that 'opss' enables the realm of WebLogic users. To only manage users internally, you can remove opss from the list of realms.

  4. Restart the server.

This enables the internal realm of users, and allow internal user accounts to be managed in the Administration pages on the Launchpad. A single default Administrator user 'dnadmin' will exist, with an initial password of 'dnadmin' that will need to be changed on first login.

If more than one realm is defined, users will need to select which realm they want to use when they log in.

3.4 Tomcat Installations

An installation of EDQ on Tomcat will use the EDQ internal authentication mechanism. This contains the single user 'dnadmin' with full administration rights. Additional users can be added through the EDQ administration web pages.

You can integrate with an external LDAP server such as Active Directory by editing the EDQ security configuration file. This is covered in Chapter 5, "Configuring External User Management (LDAP) directly with EDQ".

No login.properties file is used by default in Tomcat installations because the default setting is to use internal authentication. If additional setting are required, or LDAP integration is required, create a new security/login.properties file in the 'local' configuration directory and make changes there.