Configuring Authentication

Enterprise Tester supports the following authentication methods:

• Crowd
• LDAP
• Machine Source
• Enterprise Tester Database (local)
• SAML 2.0*
• Diagnosing Authentication

* SAML 2.0 is not configurable via the user interface and is incompatible with the other authentication methods. Please see the SAML 2.0 documentation for more details.

You can configure multiple authentication methods and set the priority of the configured methods. This means that if the primary authentication method fails, the secondary method is automatically employed, then the third and fourth.

For example, if you have configured the following authentication methods in the following order:

1. LDAP
2. Machine Source
3. Enterprise Tester Database

If a user cannot be authenticated against LDAP (the primary authentication mode in our example), authentication will automatically be attempted against the next method in the priority list (Machine Source). If the secondary method fails, the third method will be used and so on until the user is successfully authenticated or all methods have been exhausted.

To access the authentication configuration screens you will require application administration permissions to Enterprise Tester. Navigate to the Admin tab. Expand the Configuration folder and double click on Authentication.

Here you can configure new authentication methods or update existing ones. You can also arrange the priority of the configured methods as well as test your configured methods.

By default, Enterprise Tester uses the Enterprise Tester Database as the authentication method.  This method does not require configuration.  

Currently the database method cannot be removed or disabled. 

Adding Methods

• To add a method, click the ‘Add’ button then enter a name for the connection (Note: Currently editing of the connection name after creation is not supported) and select the method type.
• Once you click ‘OK’, the list of methods will refresh to include the new method.
• After creation the method is disabled, you must first configure the method, and then enable it, before it will be used.

Crowd

Crowd Authentication method provides the ability to integrate with Atlassian Crowd installations (including single sign-on).

Currently Enterprise Tester supports Authentication with Crowd however does not support Synchronization with Crowd.

When using Crowd, users will still need to be created in Enterprise Tester with the option External User selected. Ensure that the username matches the username in Crowd.

Identifying the Application

To use Crowd with Enterprise Tester you must configure a new application in Crowd, which will represent Enterprise Tester – see the Crowd user guide for details. Once the Crowd application has been added via the Crowd console you should see it in the list of applications (by clicking the ‘Applications’ tab):

In this case, our application name is the lower case ‘enterprisetester’ and this is the value that should be used for the application name in the configuration screen.

Configuring the Method in Enterprise Tester

The Crowd authentication method has the following configuration screen:

Additional Information

Integrating Enterprise Tester with Crowd is straight forward. For more information on how the Enterprise Tester Crowd implementation works, please review the blog post Integrating Enterprise Tester with Crowd.

LDAP

LDAP Authentication method provides a feature-rich authentication method suitable for use with LDAP Directories, including Active Directory.

Key Features:

• Configuration setting to allow user creation on first successful login
• Optional synchronization of Users, Groups and Group Memberships
• Manual or Automatic synchronization of Users and Groups
• Authentication only setting
• Support for SSL and StartTLS
• Deactivating users or user deletion

Enterprise Tester supports importing the following attributes into Enterprise Tester from LDAP:

1. First Name
2. Last Name
3. Email Address
4. Username
5. Phone Number

The LDAP Configuration has 2 components:

1. General configuration to your LDAP server; and
2. Synchronization set up.

General LDAP Setup

AD Explorer

AD Explorer is an open source tool that can assist with navigation of the Active Directory structure. It is useful in helping to generate the correct filter syntax settings described below. You can download the tool from the Microsoft Windows Sysinternal site.

Basic Configuration

Paging

User Configuration

Group Configuration

Group Member Configuration

Once you have completed your configuration, select ‘Save’ at the bottom of the page.

When connecting to an OpenLDAP directory, group membership synchronisation has the following limitations

1. The OpenLDAP schema must store members of a group using the full DN of a user rather than just the Uid value. E.g. Uid=Joe-Bloggs, OU = Users, OU = Department, DC = Corp, DC = Com.
2. The Group Members Filter should be configured to identify the group object type(s) that will be searched, rather than the member object type. E.g. (objectClass=posixGroup)

Group Member Configuration Example for OpenLDAP

Synchronization

The synchronization section allows you to set up the synchronization mode, the frequency of synchronization and any default groups you wish to have new users added to when being synchronized with Enterprise Tester.

Default Groups

In the Default Group section you can configure all the groups you would like users to automatically be assigned to when they are created through synchronization with LDAP or through successful authentication on first login, this is in addition to any group memberships that user may have been automatically added if “Synchronize Group Members” is checked.

Unless you specify at least one default group (and assign that group view permissions for at least 1 project) any users created as a result of using the “Create User on Successful Authentication” option will be unable to use Enterprise Tester.

Additional References

• STARTTLS
• DN (Dinstguished Name)
• Common Default Attributes Set for Active Directory

Machine

The machine source is a flexible method supporting authenticating users against the following three sources of user information:

• Active Directory
• Local Machine Users i.e. if the machine is not a member of a domain. This is also great for testing some authentication scenarios.
• AD LDS (Active Directory Lightweight Directory Services) – see here(http://technet.microsoft.com/en-us/library/cc755080%28WS.10%29.aspx) for more details.

The machine source only works with Active Directory, and not other LDAP directories. Because of this fact it’s also a great deal easier to configure – if you wish to authenticate against the same domain as the server belongs to then no configuration is required what so ever!

Machine Source Authentication method provides a simple interface for accessing the local machine or Active Directory user and group information. This is useful for small AD deployments.

Synchronization

You can configure automatic synchronization of users, groups and group memberships from Active Directory.

SAML 2.0

Enterprise Tester with SAML 2.0 capable identity provider services

Enterprise Tester supports SAML 2.0 connections to an external Identity Provider (IdP).

While ET should work with most IdPs that support SAML 2.0, we currently only test with the following IdPs:

• Okta
• Microsoft Azure Active Directory

This article will cover the basics, from the Enterprise Tester side of the configuration, and then provide an example of setting up Okta with Enterprise Tester showing both Okta and Enterprise Tester configuration.

Tips

• While a SAML 2.0 configuration is enabled, it will also be enforced when attempting to log into the application GUI. This means that local user accounts and passwords will no longer work for this purpose.
• Enterprise Tester API requests do not support SAML 2.0. The existing API authentication methods will continue to work as normal whether SAML 2.0 is configured or not.
• Enterprise Tester SAML 2.0 connections only handle authentication. User accounts, groups and permissions must be configured in Enterprise Tester separately.

SAML 2.0 Configuration Basics

Currently, a SAML 2.0 connection cannot be configured via the Enterprise Tester user interface; It must, instead, be configured via a configuration file located on the server Enterprise Tester is running on.  This is done by adding several key/value pairs to the appSettings section of the web.config file.  For more information about appSettings, please refer here.

To be able to configure several of the following properties, the IdP must be prepared first.  The process will differ in different IdPs, an example of configuring Okta is given further down in this article.

Example of the configuration as it might appear in the web.config file alongside other settings

<appSettings>
    <add key="site.root.url" value="https://apps.corp.com/et" />
    <add key="Licensing.ServerKey.GenerationMode" value="Stable" />
    <add key="migration.providerName" value="Migrator.Providers.SqlServer.SqlServer2005Dialect" />
    <add key="PathService.PackagePathSeparator" value="|" />
    <add key="aspnet:MaxHttpCollectionKeys" value="10000" />
    <add key="attachment.storage.method" value="FileSystemCas" />
<!-- SAML CONFIGURATION START -->
    <add key="SAML.Enabled" value="True" />
    <add key="SAML.Provider" value="Microsoft"/>
    <add key="SAML.Issuer" value="http://www.okta.com/cKZ3800234nlvM8s" />
    <add key="SAML.IDP" value="https://cust.okta.com/app/appname/cKZ3800234nlvM8s/sso/saml" />
    <add key="SAML.Logout" value="https://catchsoftware.com" />
    <add key="SAML.Certificate" value="-----BEGIN CERTIFICATE----- LIIC2jCCAkMCAg38MA0GCSqGSIb3DQEBBQUAMIGbMQswCQYDVQQGEwJKUDEOMAwGA1UECBMFVG9reW8xEDAOBgNVBAcTB0NodW8ta3UxETAPBgNVBAoTCEZyYW5rNEREMRgwFgY4VQQLEw9XZWJDZXJ0IFN1cHBvcnQxGDAWBgNVBAMTD0ZyYW5rNEREIFdlYiBDQTEjMCEGCSqGSIb3DQEJARYUc3VwcG9ydEBmcmFuazRkZC5jb20wHhcNMTIwODIyMDUyNzQxWhcNMTcwODIxMCUyNzQxWjBKMQswCQYDVQQGEuJKUDEOMAwGA1UECAwFVG9reW8xETAPBgNVBAoMCEZyYW5rNEREMRgwFgYDVQQDDA93d3cuZXhhbXBsZS5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC0z9FeMynsC8+udvX+LciZxnh5uRj4C9S6tNeeAlIGCfQYk0zUcNFCoCkTknNQd/YEiawDLNbxYqutbMDZ1aarys1a0lYmUeVLCIqvzBkPJTSQsCopQQ9V8WuT252zzNzs68dVGNdCJd5JNRQykpwexmnjPPv0mvj7i8XgG379TyW6P+WWV5okeUkXJ9eJS2ouDYdR2SM9BoVW+FgxDu5BmXhozW5EfsnajFp7HL8kQClI0QOc79yuKl3492rH6bzFsFn2lfwWy9ic7cP8EpCTeFp1tFaD+vxBhPZkeTQ1HKx6hQ5zeHIB5ySJJZ7af2W8r4eTGYzbdRW24DDHCPhZAgMBAAEwDQYJKoZIhvcNAQEFBQADgYEAQMv+BFvGdMVzkQaQ3/+2noVz/uAKbzpEL8xTcxYyP3lkOeh4FoxiSWqy5pGFALdPONoDuYFpLhjASZaEwuvjI/TrrGhLV1pRG9frwDFshqD2Vaj4ENBCBh6UpeBop5+285zQ4SI7q4U9oSebUDJiuOx6+tZ9KynmrbJpTSi0+BM= -----END CERTIFICATE-----" />
<!-- SAML CONFIGURATION END -->
</appSettings>

Example – Enterprise Tester with Okta

Okta is an enterprise-grade, identity management service, built for the cloud, but compatible with many on-premises applications. With Okta, IT can manage any employee’s access to any application or device. Okta runs in the cloud, on a secure, reliable, extensively audited platform, which integrates deeply with on-premises applications, directories, and identity management systems.

https://www.okta.com

Configuring Okta

1) In Okta, create Enterprise Tester integration using SAML 2.0.

2) In Okta the SAML General Settings need to contain the following.

• Single Sign URL – this must be your Enterprise Tester instance e.g https://enterprisetester/authentication/SAML2.rails
• Audience URI – this is A9CC4713-F3D5-4321-9C19-14A58E117364
  
  

3) Make sure you record IDP information when selecting the “View Setup Instructions”.

Configuring Enterprise Tester to use Okta

Add the following keys to the appSettings section in the Enterprise Tester web.config file.  Note: Values used within these appsettings will be available after completing the Okta configuration above.

1) Enable SAML Support

2) IDP Issuer

3) IDP SSO URL

4) X.509 Certificate

5) Specify logout url

Do not add an Enterprise Tester URL here or users will be automatically logged back into Enterprise Tester.The Okta applications page is a suggested url that could be added.

SHA-256 XML Signature Support

SAML 2.0 uses the SHA-256 encyrption protocol if this is not enabled on your server you will need to do the following.

On the Enterprise Tester server:

1. Download CLR Security Update
   http://clrsecurity.codeplex.com/releases/view/47764
2. Download GACUTIL from here:  http://www.microsoft.com/en-us/download/confirmation.aspx?id=19988.
3. Extract Security.Cryptography.dll assembly
4. Add Security.Cryptography.dll toGAC full path... gacutil.exe /i Security.Cryptography.dll
5. View Security.Cryptography.dll assembly gacutil.exe /l Security.Cryptography
6. Update machine.config in C:\Windows\Microsoft.NET\Framework\v4.0.30319\Config and C:\Windows\Microsoft.NET\Framework64\v4.0.30319\Config. Insert the following code block after <system.web> section in <configuration> 

<mscorlib>
 <cryptographySettings>
   <cryptoNameMapping>
     <cryptoClasses>
       <cryptoClass RSASHA256SignatureDescription="Security.Cryptography.RSAPKCS1SHA256SignatureDescription, Security.Cryptography, Version=1.6.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35"/>
     </cryptoClasses>
     <nameEntry name="http://www.w3.org/2001/04/xmldsig-more#rsa-sha256"class="RSASHA256SignatureDescription"/>
   </cryptoNameMapping>
 </cryptographySettings>
</mscorlib> 

Diagnosing Authentication

Diagnosing authentication issues can be difficult – there are a number of possible issues that can occur:

• Incorrectly configured authentication method
• Authentication methods are disabled
• Servers etc. that methods rely on cannot be contacted
• Username does not exist
• Username exists in directory, but does not exist in Enterprise Tester
• Password is incorrect

On the authentication methods toolbar select Test Authentication:

You can then check your authentication method from the screen.

Enter a username and password, then click “Run Test” button which will then attempt to authenticate the user against all enabled authentication methods.

• Overall success is reported via two fields “Success” and “User Exists”.  Both these must be true for the user to be able to log into Enterprise Tester successfully.
• By clicking the plus icon next to a row you can see authentication details