Currently, using Apache modules for authentications also requires configuring an LDAP server that Beaker can use to map REMOTE_USER to a display name and email address. The mod_lookup_identity Apache module supports a different approach, populating additional environment variables with that information. To integrate with this approach, if REMOTE_USER is set, the User does not yet exist, and LDAP is not configured, then Beaker would fall back to looking at the following environment variables for the additional user details: - REMOTE_USER_EMAIL -> user email address in database - REMOTE_USER_FULLNAME -> user display name in database See http://www.freeipa.org/page/Web_App_Authentication and http://www.freeipa.org/page/Environment_Variables#Proposed_Additional_Variables for additional details.
As Bill mentioned, this means that a user would be considered not to exist until they have first logged in to Beaker. So you would need them to log in before you can loan them a system, for example. I'm not really sure what this gains us... it adds several extra layers of abstraction (mod_lookup_identity -> sssd -> ?) but ultimately if you have a central user directory it's probably serving over LDAP, so why not just use that?
It's designed to be an escape clause for cases where there *isn't* a central LDAP server, but users aren't necessarily prepopulated in Beaker either (think participants from multiple companies sharing a single Beaker instance, but Beaker isn't the only service they're sharing). By implementing this, we offload the problem of non-LDAP entity stores to web server modules, just as we offload every authentication mechanism other than local passwords. That is, our recommended configurations become: - if you have a central LDAP store, use Apache for authentication, LDAP for identity - if you have no central LDAP store, but want to use Apache for authentication anyway, use mod_lookup_identity (or another module that sets REMOTE_USER_EMAIL and REMOTE_USER_FULLNAME) to supply the additional user details - otherwise, just use local password based accounts in Beaker So, for example, if Beaker was later integrated with FAS, our preference would be for everything OAuth related to be dealt with at the Apache layer, and the username, display name and email addressed all be passed through as environment variables.
(In reply to Nick Coghlan from comment #3) Okay, that makes sense. For some reason I was thinking mod_lookup_identity would replace the LDAP lookup support in Beaker, which doesn't seem like a good idea. But supporting it as an extra fallback makes sense.
The nice thing about these proposed variable names (REMOTE_USER_FULLNAME, etc) is that they are not specific to any particular Apache module and so they are, or can become, a defacto standard of sorts. They're not specific to mod_lookup_identity. For example mod_auth_mellon can be configured to populate any environment arbitrary environment variables with SAML attributes. We will be using that for FAS logins.
http://gerrit.beaker-project.org/4433
Beaker 22.0 has been released.