A somewhat common request for projects, especially intranets, is to provide a single sign-on (SSO) system. At a rudimentary level, an SSO system allows one site to handle all logins (authentication) for a group of sites, rather than a visitor needing a separate login for each one. For an organization with several sites it can greatly reduce the headache for its clients, customers, employees, etc increase visitor satisfaction, reduce maintenance costs, and potentially increase sales.
Another common use of an SSO system is to transparently log in visitors who are also logged into a local network where a directory service is being used to manage access across the network, e.g. the open LDAP standard, Microsoft’s Active Directory, Novell Open Enterprise Server, etc. This is most often used for local network sites and services where a level of physical security is assumed, i.e. the only people on the network are supposed to be there.
Digging deeper
At a technical level, most SSO services start with the visitor logging into one central service, the authentication site/service. After that, the visitor can then browse to other sites and services and are transparently logged in. When the visitor does connect to one of the other sites, the new site radios back to the central server to confirm the authentication. In practice this means that the visitor may be bounced back ‘n forth between a series of pages in order for the authentication to be confirmed. More commonly, though, the confirmation is handled behind the scenes on the actual servers themselves, thus greatly reducing the chance of foul play.
Either which way, these are well known and understood problems that have been solved several times before. Because of this there are many known solutions for adding SSO to a site or a group of sites. Some options for connecting to an SSO system as a client, including LDAP, SAML, CAS and OAuth, already have stable modules available for Drupal. Should there be a need to connect multiple Drupal sites together there's even a custom solution available called the Bakery module, which has been in use on drupal.org itself for many years and serves hundreds of thousands of users across its variety of sites.
And here’s one I made earlier
Because of all this, it rarely makes sense to write a custom solution; instead, an existing solution should be sought that can fit both the server and secondary / client side of the equation. When researching SSO options the most important aspect to research is what existing options are already available on the central login server, maybe as an optional extra - an existing but unused system may already exist that could save tens or even hundreds of hours of development time.
Using an existing single sign-on system provides a wealth of benefits:
- A greatly reduced amount of custom code, thus less code to manage.
- Publicly available code results in much higher security standards as anyone can audit the code.
- Known APIs result in easier integration and easier maintenance than custom code.
- Known APIs increase the likelihood of being able to find someone with experience in working with the API, rather than having to start from scratch.
- Once the pieces are in place, it’ll usually Just Work™.
.. But not the custom module!
Writing a custom SSO solution comes with many disadvantages:
- SSO systems have been built before, there are lots of options out there.
- More custom code for the site maintainers to maintain.
- It requires architecting a custom security algorithm to match the specific requirements.
- Without paying for a 3rd party service, there's no "automatic" vetting of the security algorithm outside of the immediate development team, thus a greater chance of security holes existing.
- They result in more time (and budget) spent writing solutions that already exist.
- More time (and budget) is then also spent maintaining the custom code in the future.
Hot! Code slowly!
That said, there can be a few (very few!) reasons why a custom SSO solution is required:
- There may not be an existing SSO system available for the systems that are being connected.
- One or more portions of the system may be behind custom firewalls that cannot be gotten past, which would stop the server-side account confirmation.
- Existing systems may not support unusual custom requirements that are outside of the project's control, e.g. integration with physical card or thumb readers that are mandated for use, etc.
If a project does end up needing to require a custom SSO solution, a few things should be kept in mind:
- See if there's any way to use an existing codebase and just write a plugin to handle the unique requirements; this would reduce the amount of custom code that would need to be written and maintained.
- As this opens up the castle's front gate to invaders, so to speak, secure code is of paramount importance, so make sure the code follows the Drupal security best practices.
- Include a timestamp in the algorithm and necessary logic to ensure that there’s an automatic timeout / expiration of the SSO; this will help avoid scenarios of someone using a link from a cached page on someone else’s computer.
- Ensure that all traffic is secured via HTTPS; while not perfect (the IT world is constantly uncovering details that show how it can be gotten past), it still adds a reasonable base layer of security that’s much more difficult for someone (e.g. at a coffee shop) to snoop than an unsecured connection.
- Have both the authentication logic / algorithm and the code itself vetted by a 3rd party.
- Listen to all feedback regarding the system's security and make every possible effort to remove potential avenues of attack.
- Do not attempt to write new encryption algorithms, there are plenty of highly secure algorithms supported by PHP's mcrypt library that will work with plenty of other systems.
- Use the strongest encryption algorithms supported by each platform, don't skimp on something this important, especially when there would be negligible difference in terms of system / site responsiveness for the end user.
Don't design a new mouse trap
In summary – known and trusted solutions exist for adding a single sign-on system to a website and writing a custom system should always be the last resort.
Additional Resources
Best Practices for Custom Modules | Mediacurrent Blog Post
Introducing the Mediacurrent Contrib Committee | Mediacurrent Blog Post
