8

We are leading an exercise with a public institution to install different open source tools for them to experiment and see what suits them most.

Thus, we are installing:

  • a wiki (dokuwiki)
  • mediagoblin
  • gnu social
  • etherpad
  • ethercalc

and possibly some more.

We were thinking of using LDAP to harmonize the logins.

But often it feels like the LDAP plugins are not maintained anymore, and configuration is difficult to work fine, some tools have insufficient LDAP docs.

Is it still a good idea today to do this via LDAP? Is OAuth maybe a better choice?

I know this is not a code question but what we would like to understand is if we should stick to our decision to go LDAP or if we should consider other paths. Many thanks

MadHatter
  • 78,442
  • 20
  • 178
  • 229
transient_loop
  • 459
  • 1
  • 4
  • 11

2 Answers2

13

LDAP cannot provide Single Sign On. There is a big difference between being able to use the same users and having Single Sign On, which means that you login into all systems at once, with a single login form. Otherwise, LDAP is perfectly feasible for using the same login information in all systems.

OAuth is just a protocol for doing the Sign On and it can use LDAP as backend for the user management.

Florin Asăvoaie
  • 6,932
  • 22
  • 35
  • 2
    Actually I was somehow aware of this distinction but you phrased it in a very clear and concise way, thanks. I will google about OAuth / LDAP as single-sign-on architecture, but if you have any relevant links you'd like to share - very appreciated. – transient_loop Sep 07 '14 at 20:25
1

In the university world, the Apereo [formerly Jasig] CAS system is a common way to do Single Sign On for large suites of web applications. With CAS, the user only ever enters their password on the authentication server -- individual applications validate a one-time ticket instead of seeing the user's password. This is a major security win when dealing with applications developed by many in-house groups and vendors as none of the applications ever have access to the users' passwords.

There are numerous CAS-client libraries available for most programming environments and built-in CAS support is becoming more common for applications used or sold to universities. In addition to the main "Jasig CAS Server" there are also several additional servers available, including the Ruby CAS Server and a module for Drupal that can act as a CAS server for authenticating additional applications against the Drupal database.

The Jasig CAS Server itself is written in Java and can be backed by any number of authentication handlers, including:

  • Database
  • JAAS
  • LDAP
  • Legacy
  • OAuth 1.0/2.0, OpenID
  • RADIUS
  • SPNEGO (Windows)
  • Trusted (REMOTE_USER)
  • X.509 (client SSL certificate)

The Jasig CAS server can act as an authentication source for application via a number of different protocols used for Single Sign On:

  • CAS protocol 1/2/3
  • SAML protocol 1.1/2.0
  • OAuth protocol
  • OpenId protocol

It can even be used as the authentication behind a Shibboleth provider or use a Shibboleth client as an authentication back-end.

Note: the Jasig organization is merging with the Apereo organization, so some urls might change in the future.

Adam Franco
  • 261
  • 2
  • 8
  • for the sake of full disclosure - might be worth mentioning you're affliated with the project in question – Journeyman Geek Feb 16 '18 at 10:40
  • That's a fair note. I'm affiliated with the CAS project as a user and a co-maintainer of the PHP client library to the system, phpCAS. I've filed a few bug reports and patches to the main project, but I don't believe that any have actually been integrated into the CAS project. – Adam Franco Feb 16 '18 at 15:12