Authentication

Starting October 11, 2024 (Zephyr Enterprise 8.2), the Zephyr Enterprise documentation moved from its current location on Atlassian to a dedicated, standalone Zephyr Enterprise documentation page. Please see: https://support.smartbear.com/zephyr-enterprise/docs/en/zephyr-enterprise/zephyr-administration-guides/system-setup/authentication.html


Primary Authentication: Zephyr Enterprise provides multiple options in which users can be authenticated when they log into the system. This is referred to as Primary Authentication.

Secondary Authentication: If LDAP/Crowd/Webservice/SSO is being used for primary authentication and certain temporary/migrant/external users that are not in those systems need access to Zephyr, the secondary authentication option can be turned on to allow that.

Please note that this process is only for authentication and not for synchronizing user information with these systems. After completing authentication, you may import Groups by following the instructions in Group Setup.

Primary Authentication

Internal

Administrators can leave the selection at 'Internal' to use the native Zephyr authentication system. The user ID and passwords that are stored in the User Setup section are used to authenticate users.

  • This is the default option.
  • Users can reset their own passwords by clicking on the 'Profile' link in the top right corner of their interface.

LDAP

LDAP (Lightweight Directory Access Protocol) is an Internet protocol that web applications can use to look up information about those users and groups from the LDAP server. An LDAP directory is a collection of data about users and groups.

If your organization is using an LDAP server for authentication, the Zephyr server can be set up to authenticate users using LDAP.

Zephyr Enterprise supports the most popular LDAP directory servers:

  • Microsoft Active Directory

  • Apache Directory Server (ApacheDS)

  • OpenDS

  • OpenLDAP

  • A generic LDAP directory server

Both LDAP and LDAPS (secure LDAP) are supported.


 

LDAP Configuration

Connecting to an LDAP Directory in Jira

  1. Select Administration

  2. Choose Authentication.

  3. Add a directory and select one of these types:

  4. 'LDAP' – You will be able to choose a specific LDAP directory type on the next screen.

  5. Enter the values for the settings, as described below.

  6. Save the directory settings.

Server Settings

SettingDescription
Directory Type

Select the type of LDAP directory that you will connect to. If you are adding a new LDAP connection, the value you select here will determine the default values for many of the options on the rest of the screen. Examples:

  • Microsoft Active Directory

  • OpenDS

  • And more.

Hostname

Your LDAP server in the format ldap(s)://host[:port]. Examples:

  • ldap://ad.example.com
  • ldap://ldap.example.com:389
  • ldap://opends.example.com:10389
  • ldaps://localhost.domain.com:636

Note: If you use LDAPS (secure LDAP) and your LDAPS server uses a self-signed certificate, you need to configure Zephyr to trust this certificate. See the instructions below.

Base DN

The root distinguished name (DN) to use when running queries against the directory server. Examples:

  • o=example,c=com

  • cn=users,dc=ad,dc=example,dc=com

For Microsoft Active Directory, specify the base DN in the following format: dc=domain1,dc=local. You will need to replace the domain1 and local for your specific configuration. Microsoft Server provides a tool called ldp.exe which is useful for finding out and configuring the the LDAP structure of your server.

Bind DN

The distinguished name of the user that the application will use when connecting to the directory server. Examples:

  • cn=administrator,cn=users,dc=ad,dc=example,dc=com

  • cn=user,dc=domain,dc=name

  • user@domain.name

Bind Password

The password of the user-specified above.

Search Attribute

The attribute field to use when loading the username. Examples:

  • cn

  • uid

  • sAMAccountName

Advance Settings

User Schema Settings

SettingDescription
Search Attribute

The attribute field to use when loading the username. Examples:

  • cn

  • uid

  • sAMAccountName

User Object Class

This is the name of the class used for the LDAP user object. Example:

  • user

  • inetorgperson

User Object Filter

The filter to use when searching user objects. Example:

  • (&(objectCategory=Person)(sAMAccountName=*))

  • (objectclass=inetorgperson)

User First Name Attribute

The attribute field to use when loading the user's first name. Example:

  • givenName

User Last Name Attribute

The attribute field to use when loading the user's last name. Example:

  • sn

User Email Attribute

The attribute field to use when loading the user's email address. Example:

  • mail

Group Schema Settings

SettingDescription
Group Object Class

This is the name of the class used for the LDAP group object. Examples:

  • groupOfUniqueNames

  • group

  • groupOfNames

Group Object Filter

The filter to use when searching for group objects. Example:

  • (&(objectClass=group)(cn=*))

  • (objectclass=groupOfNames)

  • (objectclass=groupOfUniqueNames)

Group Name Attribute

The attribute field to use when loading the group's name. Example:

  • cn

Group Description Attribute

The attribute field to use when loading the group's description. Example:

  • description

Membership Schema Settings

SettingDescription

Group Members Attribute

The attribute field to use when loading the group's members. Example:

  • member

User Membership Attribute

The attribute field to use when loading the user's groups. Example:

  • memberOf

Using LDAPS with a Self-Signed Certificate

If your LDAPS server uses a self-signed certificate or a certificate signed by a private CA,  you need to add it to the Java cacerts file on your Zephyr server. The cacerts file contains the trusted certificates.

To add your LDAPS certificate to cacerts, run the following command on your Zephyr server, replacing the paths with your own.

On Windows:

keytool -importcert -alias "ldapsCer"
        -keystore "C:\Program Files\Java\jre1.8.0_231\lib\security\cacerts"
        -file "C:\Users\Administrator\Documents\ldapsCer.cer"

Note: The line breaks above are added for readability. The entire command must be written on one line.

On Linux:

keytool -importcert -alias "ldapsCer" 
        -keystore "/usr/java/jdk1.8.0_144/jre/lib/security/cacerts" 
        -file "/home/ldapsCer.cer"

Anonymous Bind

When setting up your LDAP connection, we provide you with an option to connecting without requiring the Bind DN and Bind Password. To connect to LDAP without requiring this information, enable the Anonymous Bind feature when setting up LDAP.

  • Anonymous Bind is essentially an LDAP server function that allows the client to connect and search the directory (bind and search) without requiring the Bind DN and Bind Password.
  • To use Anonymous Bind, click on the checkbox to ensure it is enabled during the LDAP connection setup process.

Below the Connection Info section there will be a place to test the connections and LDAP credentials used. This is useful for a quick check to see if everything is working. The username and password here can be a user in your directory that you wish to log on the Zephyr system with. Once the information is correct you can click the Test button and if everything goes correctly, you should see a 'Validation Successful!' popup. Otherwise, start troubleshooting the setup.

LDAP Required Fields

1. What are the required fields for connecting to LDAP?

  • Open DS: LDAP Host, Base DN, and Search Attribute are required.
    • The username and password for users who can authenticate are required.
  • Active Directory: LDAP Host, Base DN, and Search Attribute.
    • The username and password for users who can authenticate are required.

2. Is a unique Organizational Unit needed for Zephyr? (Organization Unit can be - Zephyr)

  • The organizational unit can be any name. It does not necessarily have to be specific to Zephyr.

3. Is Bind DN required?

  • Bind DN is required for Active Directory.
  • Bind DN is not required for Open DS.

LDAP Setup Details and Example

The LDAP authentication system in Zephyr allows an Administrator user the advantage of using a LDAP system to authenticate Zephyr users outside of Zephyr itself. Below are detailed descriptions of the fields in the LDAP authentication setup.

LDAP Host [REQUIRED]: The IP address of your LDAP instance (default port 389). Currently does not support HTTPS.

BASE DN [REQUIRED]: Folder and Domain where the users will be that need authenticating.

  • Example 1: CN=users, DC=ad, DC=mainsystem, DC=com
  • Example 2: OU=users, DC=ad, DC=mainsystem, DC=com

BIND DN: Admin user, Folder, and Domain that will be used to search the other folders. This user/Directory Manager MUST have the ability to look through the domain for the users that need authenticating.

  • Example : CN=Admin, CN=users, DC=mainsystem, DC=com
  • PASSWORD: Password for the BIND DN Admin/Directory Manager user. The show password option will just allow the user to see the password input.
  • SEARCH ATTRIBUTE [REQUIRED]: The attribute that the BIND DN user will use to find the users it is searching for. This will likely be "samaccountname" on AD systems.
    • Example: samAccountName

Note: Once the LDAP Authentication successful, if you want to import LDAP Groups(which contains external LDAP users) please go through Group Setup.

  • Previously, when users set up their authentication for LDAP, the option to import groups would be available right away in a pop-up. This is now moved to the Import Groups tab within the Group Setup page under Administration.
  • The newly added Import Groups tab now displays which authentication system is connected (LDAP).

Crowd

If your organization is using a Crowd server for authentication, the Zephyr Server can be setup to authenticate with Crowd before allowing users to log into the system.


 
After entering the relevant 'Connection Info', the authentication can be tested by entering the username and password of a user and clicking on the 'Test' button. This provides feedback on whether the authentication system was reachable and if the authentication was successful or a failure.

Note: Once the Crowd Authentication successful, if you want to import Crowd Groups(which contains external Crowd users) please go through Group Setup.

  • Previously, when users set up their authentication for Crowd, the option to import groups would be available right away in a pop-up. This is now moved to the Import Groups tab within the Group Setup page under Administration.
  • The newly added Import Groups tab now displays which authentication system is connected (Crowd).

WebService

If your organization is using a different authentication system, then you could write a WebService that the Zephyr Server can call to authenticate against before allowing users to log into the system.


 
After entering the relevant 'Connection Info', the authentication can be tested by entering the username and password of a user and clicking on the 'Test' button. This provides feedback on whether the authentication system was reachable and if the authentication was successful or a failure.

Single Sign-On (SSO) with SAML 2.0

If your organization is using Single Sign-On (SSO) for authentication, the Zephyr Server can be setup to authenticate with it before allowing users to log into the system.

With SSO set up and enabled, the login flow will redirect you straight to the SSO login page and after entering in the correct credentials, it will redirect and log you into Zephyr. This minimizes the amount of steps and redirects to get logged into Zephyr.

You can enable Auto-Provisioning when setting up your SSO.

  • Auto-Provisioning will automatically create a user account for any new user who attempts to log in to Zephyr with SSO.
  • New user accounts created this way will only receive the Dashboard User Role, and these accounts will not consume a license.
  • This can be enabled/disabled on the Authentication page under the Administration section of Zephyr.
    • To enable this, you must provide the SAML attributes from your external SSO system with the Zephyr attributes so that Zephyr can create users automatically.

See below for the configuration fields required for setting up SSO:

  • The Test button allows you to check the specified URL. Clicking the button opens a new tab. If the login page of your SSO provider is opened in the tab, you have specified the correct URL.
  • If SSO is configured incorrectly, users will not be able to connect to Zephyr. To bypass SSO authentication, the administrator can navigate to the following page:

    http(s)://<server>:<port>/flex/html5/internal-login

    and log in using the login and password of the account with the user ID 1 (userId=1). By default, both the login and password of the account are test.manager.

For an example of setting up Okta in Zephyr, please refer to SSO Setup with Okta in Zephyr.

For an example of setting up Azure AD in Zephyr, please refer to SSO Setup with Azure AD in Zephyr.

Secondary Authentication

If LDAP/Crowd/Webservice/SSO is being used for primary authentication and certain temporary/migrant/external users are not in those systems and need access to Zephyr, the secondary authentication option can be turned on to allow that.
Those users are then authenticated based on the user ID and password set up for them in the User Setup section.

To enable secondary authentication:

  1. Go to Administration > System Setup > Customizations.
  2. Click Miscellaneous in the Advanced section.
  3. Select the Enable Secondary Authentication check box in the subsequent dialog and click Save.


 

Benefits of enabling Secondary Authentication

  • When Secondary Authentication is enabled, Internal users can also log in If the Authentication is set to any service.

  • Enable secondary authentication to allow some users to use internal credentials bypassing your primary authentication mechanism (LDAP, SSO, etc.). These users will be able to login using their username/passwords.

  • Disable secondary authentication to ensure that users can only log in via your primary authentication mechanism.