View Source

The function or feature discussed below is only relevant to members of the beta programme

OpenAthens can connect directly to an LDAP server so that you do not have to issue personal accounts for your users (you will still need your OpenAthens administrator account though). Anything that uses standard LDAP protocols is acceptable so this works very well 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.

Preparation

Before you start you will need:

An LDAP server that can be queried from outside of your network.
- If this is not possible, an ADFS connection might be what you need instead.
A member of your IT team to supply or enter the connection details (jump to details).
A copy of your LDAP server's certificate (base 64 encoded X.509, often called pem format).

Add the connection

In the administration interface go to Management > Connections

Click the add button on the left and select LDAP
Have your colleague from the IT team complete the form and click add at the bottom.
If your connection requires a certificate, the status panel will show errors until it is added:

_{You can hover over the panel for more details about an error}

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

. This will be converted to a summary panel:
Save changes
The status panel will update and should now show success if it did not before
You should be able to use the test authentication button now with your own username and password.

Final steps

Once you have defined the login box text to suit your organisation (on the login page tab) you are ready to deal with the final two configuration areas:

Permission set rules so that your users as assigned an appropriate set of resources
Attribute mappings so that OpenAthens can make use of data available from your LDAP

When you're ready to go live, check both the live and visible boxes and then save. Your new connection should be available on the authentication point in a few seconds.

How to test

There will be more functions available later, but during the beta you can just set it as live and visible and start using it on the authentication point

How to use LDAP alongside MD accounts

If this is your only local connection, 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 at which point a button that takes the user to you becomes available.

Users with OpenAthens accounts can still log in 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.

PLACEHOLDER - SCREENSHOT OF NEW AP WHEN AVAILABLE

What the fields are for

Field	Explanation
Name	The name of the connection as it will appear to users at our authentication point.
Directory type	Used to set default values in other places on the form.
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 standard but ldaps:// can be chosen if you prefer.
Admin bind DN	The full distinguished name of a user that can connect and view all the users you need to authenticate, e.g: cn=openathens,cn=users,dn=ad,dn=yourdomain,dn=net
Bind password	The password for the user specified in the admin bind
Base DN	The distinguished name of your directory, e.g: dn=ad,dn=yourdomain,dn=net
Filter	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
DIsplay name attribute	This defaults in AD to be 'sAMAccountName' and in LDAP to 'cn'. It is the value displayed in account lists and audit where you would normally see the OpenAthens username. You can choose any attribute.
Unique user attribute	This should be an attribute that will always be unique to that user and it is used in the generation of targetedIDs. It defaults in AD to 'objectGUID' and in LDAP to 'cn'. If you are migrating from another local authentication system, you may want this to match your old setting.
Salt value	The salt used to generate a targetedID. This is intended to be used when you are migrating from something like OpenAthens LA to MD and is provided so that your users can have the same targetedID value when they change systems. Leaving it blank is usually the correct thing to do (uses the same seed as your MD accounts). Modifying this after you go live will change the identifiers seen by service providers for all your users which is rarely desirable.
Status	Live & visible = production ready. Users will be able to access this login at the authentication point. If you have only one connection 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 the supplied test URL (when available), but the authentication point will only use OpenAthens accounts. Not live = cannot be used. The visibility setting is ignored. Changes to the status usually take effect within moments.
Create local accounts	Automatically - any user authenticated by your system is deemed ok and will be accepted by the system Manually - only user IDs you have previously uploaded will be accepted by our systems. See how to limit which local accounts can log in

Example filters

Instead of specifying only a username field, the use of a filter allows compatibility 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 be set to 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})(sAMAccountName=${uid}))) - An example where the default has been modified to accept either the email address or the Windows username as the user ID along with the object category of person. The 'or' here is signified by the easy to miss pipe just before (mail=...

(&(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 the primary email address as the username and additionally limited to users in the students security group.

If IT want to know what happens during an authentication...

During set-up and configuration (including testing of mappings)

There is an admin bind to your directory to check status and read the available attributes for mapping

During user authentications

There is an admin bind to your directory to discover the FQDN of the user based on whichever attribute you have defined as the userID
Once the user's FQDN is known, it is used with the user's password to bind for authentication and request of any mapped attributes

All connections from us will come from specified IP addresses, available from the service desk, and any changes to these would be communicated in advance.