2012-01-10, 01:42 PM
First, the TL;DR: Provide an interface for making external user authentication possible.
Second, a note: I've seen three threads in which social media integration was suggested. That is not what I am proposing here, and I want to get that out of the way (although use of social networks for login could come under this).
Now, my suggestion.
What I'd like to see is a framework which would allow the writing of plugins to authenticate users against an external database, be that Windows user-accounts, PAM running on the local machine, an LDAP directory, a social network's authentication API, et cetera et cetera et cetera. Ideally, there would be hooks for:
Personally, I want it because I'd like to use MyBB in a situation where we'd like to have single sign-on (currently it's all on one Debian server, so everything else uses PAM, but we might have to change once things start moving onto other hosts, as they eventually will. The specific auth mechanism is not the question here).
Implementation:
Presumably, the changes needed would be an alteration to the database schema, and modifications to code relevant to users - I think only (that which in 1.6 resides in) inc/functions_user.php, but I'm not familiar enough with the code to say for sure - such that it tested to see if a user was using extauth, and passed on to the appropriate plugin if so.
How complex this would be would depend in part on a detail of implementation: Would extauth allow accessing a user account using multiple sets of credentials (ie adding an authentication source to an account), or using only one (that is, replacing the authentication mechanism built into MyBB as it is). The latter would be simpler, because there could be a per-user field in the database that indicated which authentication backend to use, whereas the former would require either producing an interface for the user to choose how to log in or trying each available method in turn until one returned success, or they all returned failure. Replacement authentication methods are what I'm after, but those who want social media integration would surely prefer additional methods. It would be possible to do both, of course, by having a setting that forces the use of (a specified authentication backend) when the internal database would otherwise be used.
I... hope that makes sense. I'm not proposing a full external authentication module, but an interface that would make it possible to write one without having to maintain a set of patches from the official code. Thanks for taking the time to read this wall of text.
EDIT: Incidentally, when my access to a workable development platform is somewhat more stable (I am, for complex reasons, travelling rural India without a laptop until May) I'll be trying to produce a mod for 1.6 that does what I'm proposing here, along with a sample plugin for PAM authentication. I have no idea how much success I'll have, but it seems worth doing, especially since 2.0 won't be released until it's ready, which - as we've repeatedly been told - won't be any time soon.
Second, a note: I've seen three threads in which social media integration was suggested. That is not what I am proposing here, and I want to get that out of the way (although use of social networks for login could come under this).
Now, my suggestion.
What I'd like to see is a framework which would allow the writing of plugins to authenticate users against an external database, be that Windows user-accounts, PAM running on the local machine, an LDAP directory, a social network's authentication API, et cetera et cetera et cetera. Ideally, there would be hooks for:
- Determining whether a user exists (used only for account setup, really)
- Authenticating a user
- Changing a user's password*
- Creating a user*
- Deleting a user*
Personally, I want it because I'd like to use MyBB in a situation where we'd like to have single sign-on (currently it's all on one Debian server, so everything else uses PAM, but we might have to change once things start moving onto other hosts, as they eventually will. The specific auth mechanism is not the question here).
Implementation:
Presumably, the changes needed would be an alteration to the database schema, and modifications to code relevant to users - I think only (that which in 1.6 resides in) inc/functions_user.php, but I'm not familiar enough with the code to say for sure - such that it tested to see if a user was using extauth, and passed on to the appropriate plugin if so.
How complex this would be would depend in part on a detail of implementation: Would extauth allow accessing a user account using multiple sets of credentials (ie adding an authentication source to an account), or using only one (that is, replacing the authentication mechanism built into MyBB as it is). The latter would be simpler, because there could be a per-user field in the database that indicated which authentication backend to use, whereas the former would require either producing an interface for the user to choose how to log in or trying each available method in turn until one returned success, or they all returned failure. Replacement authentication methods are what I'm after, but those who want social media integration would surely prefer additional methods. It would be possible to do both, of course, by having a setting that forces the use of (a specified authentication backend) when the internal database would otherwise be used.
I... hope that makes sense. I'm not proposing a full external authentication module, but an interface that would make it possible to write one without having to maintain a set of patches from the official code. Thanks for taking the time to read this wall of text.
EDIT: Incidentally, when my access to a workable development platform is somewhat more stable (I am, for complex reasons, travelling rural India without a laptop until May) I'll be trying to produce a mod for 1.6 that does what I'm proposing here, along with a sample plugin for PAM authentication. I have no idea how much success I'll have, but it seems worth doing, especially since 2.0 won't be released until it's ready, which - as we've repeatedly been told - won't be any time soon.