Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

Version 1 Next »

The authentication providers you configure for your XNAT determine how your site's users will be able to log in. If you do not specify any authentication providers, XNAT will use only the default database authentication provider. The 'admin' and 'guest' accounts are the two database accounts that come with XNAT. Many sites also want users to be able to log in via LDAP. This page explains how to configure one or many LDAP authentication providers for your XNAT. If you have already set up LDAP for an earlier version of XNAT and want to upgrade to 1.7, you will need to put your old LDAP configuration in a jar in your plugins directory instead of in the services.properties file.

Adding Configuration to Plugin

Properties files for each authentication provider can either be added to an existing plugin, added to a plugin your create for all the authentication providers, or placed in separate plugins for each provider. One benefit of putting each provider in a separate plugin is that you can then manage each of them separately through Administer->Site Administration->Manage Plugins. Regardless of which plugins you put them in, each file should be at this location relative to the top level of the plugin: META-INF/xnat/auth/PROVIDER_ID-provider.properties.

Local Database Providers

By default, users can log into XNAT only using credentials that are stored in a local database. If this is the only way you want people to be able to log in to your XNAT, then you will not need to specify any authentication providers. However, if you specify any authentication providers, XNAT will no longer assume that you want the local database provider, so if you want both LDAP and database logins to be options for your users, you will need to create a properties file for the database provider (in addition to creating a properties file for the LDAP one). Fortunately, the database properties file is very simple. Your localdb-provider.properties file should look something like this:

name=Database
id=localdb
type=db

LDAP Providers

For each LDAP you want your users to be able to use to log in to XNAT, you will want to create a separate properties file. Each of these files should look something like this:

name=LDAP
id=ldap1
type=ldap
address=ldap://ldapurl:389/dc=my,dc=domain
userdn=cn=MyServiceAccount,ou=MyGroup,dc=my,dc=domain
password=MyPassword
search.base=ou=people
search.filter=(uid={0})

This configuration has changed slightly as of 1.6; 1.5 and older configurations (such as those referenced here) will not work with 1.6.

In particular, if you are copying the search filter over from your 1.5 authentication.properties, replace

%USER% (a homebrewed syntax used by XNAT 1.5)

with

{0} (Spring Security syntax)

You can also configure XNAT to also support LDAP authentication.  It's known to work with ActiveDirectory and OpenLDAP; other LDAP implementations have not been tested but should work too.

To authenticate against an LDAP server, or multiple servers, you can add these servers to services.properties. Users will then be able to log in using their LDAP credentials and will not have to remember a new username and password.  To enable LDAP authentication, you must provide some information about the LDAP server you want to use.  An LDAP properties template is included in services.properties (look for provider.ldap1.*).  Fill in this template appropriately.  Here's an example:

provider.ldap1.name=LDAP
provider.ldap1.id=ldap1
provider.ldap1.type=ldap
provider.ldap1.address=ldap://ldapurl:389/dc=my,dc=domain
provider.ldap1.userdn=cn=MyServiceAccount,ou=MyGroup,dc=my,dc=domain
provider.ldap1.password=MyPassword
provider.ldap1.search.base=ou=people
provider.ldap1.search.filter=(uid={0})

These values would be used if you wanted the provider to access an LDAP server with URL ldap://ldapurl:389/dc=my,dc=domain.  Authentication would be performed by attempting to bind with the DN uid=<user-login-name>,ou=people,dc=my,dc=domain.  

provider.ldap1.name is what you want your users to see. On the login page, there is a dropdown from which users select the provider they want to use. If you want the database provider to be listed as "XNAT" instead of "Database", simply set

provider.db.name=XNAT

provider.ldap1.id uniquely identifies the provider in case there are multiple providers of a given type. If you add a second ldap provider, it should have a different ID ("ldap2" is fine).

provider.ldap1.type indicates what type of provider it is. The two types that are currently supported are db and ldap.

provider.ldap1.userdn/provider.ldap1.password are credentials for the LDAP account that you're connecting with to perform the authentication.  Typically this is a service account, not an actual person's account.

provider.ldap1.search.filter is the LDAP field that contains the user's login name.  This may be different depending on your LDAP implementation.

 An Active Directory implementation will need something like the following:

provider.ldap1.search.filter=(sAMAccountName={0})

With OpenLDAP it might be more like this:

provider.ldap1.search.filter=(uid={0})

Now that the template is complete, add the ldap1 provider to the provider list:

provider.providers.enabled=db, ldap1

Restart Tomcat and the LDAP authentication should be enabled (you'll see a dropdown list on the home page).

If you have a need for multiple LDAP servers, just set

provider.providers.enabled=db, ldap1, ldap2

 and then create a new set of properties for ldap2.

  • No labels