How Can We Help?
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:
- LDAP
- Machine Source
- 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
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:
| Field | Description | Example |
|---|---|---|
| Crowd Server | Crowd URL | http://localhost:8095/crowd/services/SecurityServer |
| Application Name | Name of the application in Crowd | e.g. EnterpriseTester |
| Password | Password to access Crowd | e.g. Password |
| Convert Localhost to IPV6 | When enabled, the Crowd authentication method will automatically transform IPV4 loopback addresses and localhost host names to the equivalent IPV6 loopback address, when generating remote_address validation factor to be supplied to Crowd. It’s only necessary to enable this if you find validation is failing. Often this occurs when Enterprise Tester and Crowd are both running on the same server. |
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:
- General configuration to your LDAP server; and
- 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
| Field | Description | Example |
|---|---|---|
| LDAP Server | Enter LDAP Serve Name or IP Address | 123.123.1.234 |
| Port | Port number associated with the LDAP Server | 389 |
| Protocol Version | Version of LDAP | Version 2 (required for some older OpenLDAP installations) or Version 3 (Active Directory and new LDAP Directory implementations) |
| Authentication Type | Authentication Protocol | Anonymous, Basic, Negotiate, NTLM, Digest, Sicily, Dpa, Msn, External or Kerberos |
| SSL | Encryption Protocol | Check if using SSL |
| StartTLS | Encryption Protocol | Check if using StartTLS |
| Base DN | Name of the root node in LDAP from which to search for users | cn=users,dc=example,dc=com |
| Additional User DN | Prepended to the Base DN to limit the scope when searching for users | |
| Additional Group DN | Prepended to the Base DN to limit the scope when searching for groups | |
| Bind DN | Bind DN is the user and the node in LDAP where the user can be found (this is the user Enterprise Tester will authenticate to the LDAP directory as – they must have sufficient rights to query the LDAP directory) | Either a value distinguished name such as “cn=user,cn=Users, dc=example,dc=com”, an username@domain e.g. “joebloggs@mycompany.local” or left blank for anonymous authentication. |
| Bind Password | Password for the Bind DN user | Password, or left blank for anonymous authentication. |
| Search Attribute | The attribute in LDAP holding the login name | uid (common for OpenLDAP) or sAMAccountName (Active Directory) |
Paging
| Field | Description | Example |
|---|---|---|
| Enable Paging | When enabled, users will be returned in multiple pages rather than a single list. This is useful when you have a large number of users configured in LDAP, and where a non-paged request will fail because the query returns more than the allowable maximum – this should always be enabled for Active Directory. | True |
| User Page Size | Specify the number of users to return per page. The default value is 100. This value should ideally be configured to be the same as the maximum number of results which can be returned from a single query to ensure the least number of round trips when querying LDAP. | 1000 |
| Group Page Size | Specify the number of groups to return per page. The default value is 100. This value should ideally be configured to be the same as the maximum number of results which can be returned from a single query to ensure the least number of round trips when querying LDAP. | 500 |
User Configuration
| Field | Description | Example |
|---|---|---|
| Object Filter | Filter user for retrieving all users | (&(objectCategory=Person)(sAMAccountName=*)) |
| Search Filter Template | Filter used for searching by name or partial name. | (&(objectCategory=Person)(sAMAccountName={0})) |
| User Name Attribute | User Name Attribute | uid (common for OpenLDAP) or sAMAccountName (Active Directory) |
| First Name Attribute | First Name Attribute | givenName |
| Last Name Attribute | Last Name Attribute | sn |
| Email Attribute | ||
| Telephone Attribute | Phone Attribute | telephoneNumber |
Group Configuration
| Field | Description | Example |
|---|---|---|
| Object Filter | Group Object Filter | (&(objectCategory=Group) |
| Search Filter Template | Group Search Filter Template | (&(objectCategory=Group)(cn={0})) |
| Name Attribute | Group Name Attribute | cn |
| Description Attribute | Group Description Attribute | description |
Group Member Configuration
| Field | Description | Example |
|---|---|---|
| Group Member Attribute | Members attribute of group | member |
| Group Members Filter | Members Attribute Filter | (objectClass=user) |
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
- 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.
- 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
| Field | Description | Example |
|---|---|---|
| Group Member Attribute | Members attribute of group | memberUid |
| Group Members Filter | Members Attribute Filter | (objectClass=posixGroup) |
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.
| Field | Description | Example |
|---|---|---|
| Mode | Select the type of integration you would like with LDAP | Authentication only – LDAP is used to authenticate users onlySynchronization – Users, Groups and Group Memberships are automatically created in Enterprise TesterCreate User on Successful Authentication – New users are automatically created on first login if they are successfully authenticated in LDAP |
| Schedule | Synchronization Frequency | Manual Synchronization, Every Hour, Every 2 Hours, Every 4 hours, Every 8 Hours and Every 24 Hours. |
| Synchronize Users | Select to synchronize Users from LDAP | Check to synchronize users |
| Synchronize Groups | Select to synchronize Groups from LDAP | Check to synchronize Groups |
| Synchronize Group Members | Select to synchronize Groups from LDAP | Check to synchronize Group Members for each user |
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
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.
| Field | Description | Example |
|---|---|---|
| Type | The type of users source, possible options are: Active Directory Domain, Active Directory LDS Store, or Local Machine | Local Machine |
| Name | Optional name of the server (either as the source of “local” users, or the active directory domain controller) | corp01 |
| Container | Use this only for Active Directory Domain or Active Directory LDS Store. This is the distinguished name of a container object for users/groups, this should be left blank for Local Machine users. | cn=users,dc=mycompany,dc=com |
| User Name | Username to access the directory/machine (can normally be left blank). | Administrator |
| Password | Password to access the directory/machine (can normally be left blank). | ******** |
| Binding Type | The authentication mode:Negotiate: The client is authenticated by using either Kerberos or NTLM. When the user name and password are not provided, the Account Management API binds to the object by using the security context of the calling thread, which is either the security context of the user account under which the application is running or of the client user account that the calling thread represents.Simple Bind: The client is authenticated by using the Basic authentication. Caution Communications may be sent over the Internet in clear text if the SecureSocketsLayer option is not specified with simple bind. | Simple Bind |
| Sealing | The data is encrypted by using Kerberos. This flag can only be used with the Negotiate context option and is not available with the simple bind option. | Unchecked |
| Secure Socket Layer | The channel is encrypted by using the Secure Sockets Layer (SSL). Active Directory requires that the Certificate Services be installed to support SSL. | Unchecked |
| Sever Bind | Specify this flag when you use the domain context (Active Directory Domain type) if the application is binding to a specific server name. | Checked |
| Signing | The integrity of the data is verified. This flag can only be used with the Negotiate context option and is not available with the simple bind option. | Unchecked |
Synchronization
You can configure automatic synchronization of users, groups and group memberships from Active Directory.
| Field | Description | Example |
|---|---|---|
| Mode | Select the type of integration you would like with the machine source. | 1. Authentication only –AD is used to authenticate users only 2. Synchronization – Users, Groups and Group Memberships are automatically created in Enterprise Tester 3. Create User on Successful Authentication – New users are automatically created on first login if they are successfully authenticated in LDAP |
| Schedule | Synchronization Frequency | Manual Synchronization, Every Hour, Every 2 Hours, Every 4 hours, Every 8 Hours, Every 24 Hours |
| Synchronize Users | Select to synchronize Users from the machine source | Check to synchronize users |
| Synchronize Groups | Select to synchronize Groups from the machine source | Check to synchronize Groups |
| Synchronize Group Members | Select to synchronize Groups from the machine source | Check to synchronize Group Members |
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:
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.
| Key | Purpose | Default Value | Example | Notes |
|---|---|---|---|---|
| SAML.Enabled | To turn SAML support on or off | false | <add key=”SAML.Enable” value=”true”/> | Required setting |
| SAML.Provider | Used to switch between implementation styles of SAML 2.0 | n/a | <add key=”SAML.Provider” value=”Microsoft” /> | Optional setting This should usually be set to “Microsoft” but may need to be omitted all-together, depending on IdP |
| SAML.Issuer | IDP Issuer URL | n/a | <add key=”SAML.Issuer” value=”http://www.okta.com/cKZ3800234nlvM8s”/> | Required setting Requires IdP configuration first |
| SAML.IDP | IDP SSO URL | n/a | <add key=”https://cust.okta.com/app/appname/cKZ3800234nlvM8s/sso/saml”/> | Required setting Requires IdP configuration first |
| SAML.Certificate | X.509 Certificate | n/a | <add key=”—–BEGIN CERTIFICATE—– certificate body —–END CERTIFICATE—–“/> | Required setting Should be entered as a single line and should include the begin and end certificate tags Requires IdP configuration first |
| SAML.Logout | URL that a user will be redirected to if they choose to log out of Enterprise Tester | Enterprise Tester Login URL | <add key=”SAML.Logout” value=”https://myapps.microsoft.com”/> | Optional setting If not configured, a user choosing the logout option will be automatically logged back in again provided there session is still active with the IdP. |
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.
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
<add key="SAML.Enabled" value="true" /> |
2) IDP Issuer
<add key="SAML.Issuer"value="<IDP Issuer>"/> |
3) IDP SSO URL
<add key="SAML.IDP"value="<IDP SSO URL>"/> |
4) X.509 Certificate
<add key="SAML.Certificate"value="<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.
<add key="SAML.Logout"value="https://your_selected_logout_page"/> |
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:
- Download CLR Security Update
http://clrsecurity.codeplex.com/releases/view/47764 - Download GACUTIL from here: http://www.microsoft.com/en-us/download/confirmation.aspx?id=19988.
- Extract Security.Cryptography.dll assembly
- Add Security.Cryptography.dll toGAC
full path... gacutil.exe /i Security.Cryptography.dll - View Security.Cryptography.dll assembly
gacutil.exe /l Security.Cryptography - 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