Identity gifts wax poor when integration proves unkind – Hamlet Act III Scene I
What was Shakespeare referring to in this classic scene? Well he might not have been thinking about identity management and Drupal, but its not a stretch to see that he could be. If you’re building a Drupal site for enterprise users, which modules will you use so users can login? Unlike when you create a Drupal site for the general public, enterprise Drupal sites are just another application in the enterprise and don’t generally own the identity data or repository (typically AD). You have a few options.
The “easiest” option is to use some of the modules out there for self registration to allow enterprise users to register for the site and set their password. I put easiest in quotes because this seems straight forward. Its easy on the initial developers because they aren’t dependent on an external identity service. There are plenty of registration modules too. Beyond the ease of initial development the term “easy” quickly breaks down though. From a security standpoint, are you rotating passwords per corporate policy? Can you provide the reports auditors need? Does the admin service for Drupal need multi-factor authentication?
After self registration modules, most developers would turn towards one of the LDAP or Active Directory modules out there. Most enterprises have Active Directory, so this seems like another “easy” solution. Users don’t need to remember a new password and your team doesn’t need to manage passwords at all. This option may not be as easy as expected either. First off, most enterprises have multiple Active Directory forests. Microsoft has been preaching to enterprises to segment their forests by some kind of logical grouping for 15 years. This means that any application that needs to interact with AD will need to know how to work with multiple ADs. Also, the person paying for your Drupal site will generally not own AD, so any direct connections may be harder then you anticipate. Finally, adding an external dependency on AD can slow down your development. Do your developers need a constant connection to AD to work? What about users with different roles? Do your automated tests need to take users from every forest into account? Your Drupal site just got much more complicated.
What if your app is running on a public cloud? You might not even be allowed to connect directly to AD. More modules, there are several that support SAML2 and identity federation. This might eliminate the connection problem, but doesn’t really solve how users get into Drupal in the first place and are mapped to roles. It also doesn’t solve the problems caused by adding an external dependency. Are you using the same certificates for each environment? How do individual developers test on their local instances?
Tremolo Security’s Unison can help get your site into your customer’s environment without derailing many of the benefits of Drupal development. Our integration with Drupal gives you the best of both worlds. Your developers can continue to develop in the light-weight branches they’re use to. Unison creates and updates user accounts “Just In Time” as users login, eliminating the need to connect to an external dependency for identity services. The time to integrate is very quick, as shown in our demos. We even provide web based identity provider to make it easier to test your applications.
To see if Unison can help your Drupal deployment, you can register for an evaluation license and download Unison or just reach out to us with a question.
