LDAP Authentication service requires that your application either speaks standards-based LDAPv3 over SSL or – if you're developing the code in house – that the language you're using has an API that capable of speaking LDAPv3 over SSL.

Configuring LDAP Authentication

If your application is appropriate for LDAP authentication service, here's what you need to get started:

  1. Sign up for our LDAP Customers Mailing List
  2. Ensure that your application has an LDAP API, and that the API supports SSL-ized LDAP connections.
  3. Contact us to register your app. Your request should include the following:
    • Application or Service Name
    • Service URL
    • Brief Service Description
    • Access Requirements (e.g. who can use this app? students, employees, selected individuals, etc.)
    • Authorization Mechanism (e.g. how is access managed? affiliation lookup, internal authorization table, etc.)
    • Technical Contact (name & e-mail address)
    • Department Code of Service Owner
    • Support Contact (phone or URL)
    • Include in our Service Catalog?
  4. We'll provide you with a privileged dn (account) in our LDAP service with which your app can sign-in.
  5. Use the LDAP API within your app to authenticate a UCSBnetID by:
    • connect to our ldap service using LDAP-over-SSL
    • sign-in (bind) to the server using the credentials issued for your application
    • search for the UCSBnetID you'd like to authenticate and retrieve the entry's "distinguished name" (dn)
    • attempt to bind using the entry dn and password
    At each of these steps your application should test the return value from the API and – upon error communicate the appropriate error in your application UI.

Note that the UCSBnetID is not necessarily permanently assigned to an individual (see our information on UCSBnetID Reissue for details). If your application must store a foreign key we recommend using the ucsbCampusID. For those who must store the UCSBnetID with their application (e.g. for authorization purposes) we recommend that you sign up for our UCSBnetID Reissue Notification mailing list so that you can be notified when such changes occur. Contact our help desk for further information.

Coding for LDAP Authentication

Although Identity Services can't provide specific assistance on how to write code using the LDAP API in your language of choice, we can describe in general terms how your authentication code should work:

  1. Try to connect to our ldap service using the published connection parameters. If you're unable to connect, throw an error that includes the specific error message returned by your LDAP API.
  2. The LDAP authentication call is known as "bind". To call the bind method you'll need the account's unique identitfier – called a distiguished name (DN) – and password.
  3. Assemble the application DN using the format appropriate for the LDAP service to which you're connecting. For the ldap.ucsb.edu you'll need to use "uid=[app_account_userid],ou=applications,o=ucsb".
  4. Call the bind API using the application DN and password that we've issued to your service. If you're unable to bind, throw an error that includes the specific error message returned by your LDAP API. Typically a failure here
  5. Once you've successfully authenticated at the application level you can now attempt to authenticate the end user. First assemble the user DN using the format appropriate for the LDAP service to which you're connecting. For the ldap.ucsb.edu service it's "uid=[ucsbnetid],ou=people,o=ucsb".
  6. Now call the bind API using the user's DN and password. If you're unable to bind as the user, this means they've provided an incorrect UCSBnetID or password.
  7. Once you've bound successfully as the user, you'll likely want to retrieve some attributes about the individual to identify them with your app.
  8. Finally, you'll want use the values of the attributes you retrieved to provide authorization for you app. For instance, use the value of ucsbAffiliation to restrict access to allow only employees to use your app. We strongly recommend that you do not skip this step, since there a number of individuals with UCSBnetIDs for whom you may not want to provide access (e.g. academic affiliates, contractors, library patrons, etc.)