This function is in beta so may not be available to you. Documentation may not be complete.

OpenAthens can connect directly to an LDAP server so that you do not have to issue accounts yourself. Anything that uses standard LDAP protocols is acceptable so this works with ActiveDirectory too.

As well as the ability to use local accounts instead of maintaining a separate set of credentials, accesses to federated resources that already involve discovery (identifying the users' home organisation) will take the user directly to your LDAP login at our authentication point - no further discovery is required.


Before you start you will need:

Add the connection

In the administration interface go to Management > Connections

  1. Click the add button on the left and select LDAP

  2. Have your colleague from the IT team complete the form and click add at the bottom.

  3. At this point the status panel will probably show failures for connection and bind:

  4. Switch to the certificate tab and paste in the contents of the certificate file which should look similar to this:

    -----END CERTIFICATE-----
  5. . This will be converted to a summary panel:

  6. Save changes

  7. At this point the status panel will update and should now show success if it did not before

  8. You should be able to use the test authentication button now with your own username and password.

What the fields are for


The name of the connection as it will appear to users at our authentication point. This should be a form of your organisation name so users can find it in a list when they need to.

Directory type

Used to set default values where Active Directory is different from the underlying LDAP standard.

Server host

The address where OpenAthens can connect to your server. This address will need to be accessible by our services from outside of your network.

Server port

The port that your server uses for LDAP traffic. You can specify a non-standard port if necessary.

Connection type

The form of security used. StartTLS is the industry standard but ldaps:// can be chosen for older systems.

Admin bind DN

The full distinguished name of a user that can connect and view all the users you need to authenticate, e.g:


Bind password

The password for the user specified in the admin bind

Base DN

The distinguished name of your directory, e.g:



Allows you to specify the username field, plus limitations where necessary. The field you identify as =${uid} will be used as the username in login dialogs

Live & visible = production ready. Users will be able to access this login at the authentication point. It will become the default login whenever your organisation is known (e.g. for any resources where access involves your entityID).

Live and not visible = testing mode. Will work with a crafted test URL, but the authentication point will only use OpenAthens accounts.

Not live = cannot be used. The visibility setting is ignored.

Changes to the status can take up to PLACEHOLDER-TIME to go live.

Example filters

Instead of specifying only a username field, the use of a filter allows comparability with a greater variety of LDAP structures - e.g. where including all valid users requires binding to a node that will also include invalid users, the filter can exclude the invalid users.

cn=${uid} - The default LDAP filter using common name as the username

mail=${uid} - An example LDAP filter using email address as the username

(&(objectCategory=Person)(sAMAccountName=${uid})) - The Default ActiveDirectory filter uses the windows login as the username and requires the user to have an object category of person.

(&(objectCategory=Person)(mail=${uid})(memberOf=cn=students,dc=domain,dc=com)) - An example ActiveDirectory filter still requiring the user to have an object category of person but this time using email address as the username and additionally limited to users in the students security group.

How to test

By putting the connection into live but not visible mode you will need to craft a URL to test with as follows:



How to use LDAP alongside MD accounts

Once you set this as both live and visible it becomes your default way for users to log into OpenAthens where the system knows the user is yours - e.g. where the user has selected your organisation from a WAYF on a federated resource or remembers a users previous choice. Where the system does not know the user is yours only the OpenAthens account login will appear, but the user can find you via the search box.

Users with OpenAthens accounts can still log in though by clicking the OpenAthens link on the page to switch their input. This gives you options for providing access to users who you do not have in your directory such as temporary users, walk-ins or test accounts for suppliers.