David Raynes

The following is an email that I sent to some of the folks at Six Apart about two weeks ago. I thought I should share it with the rest of the community.

As we've discussed before, I know that there are corporate customers of yours that are quite anxious for the ability to make use of their existing authentication systems in their blogs. We have also discussed hooking up MT and TypeKey as a start to that, and even developing an LDAP to TK/MT mapping of sorts. For the government customers I see at my day job, and I'm sure plenty of corporate customers as well, relying on something over which they are not in direct control (i.e. TK) is not an option for any number of reasons (e.g. corporate policy, or just not being connected externally at all). Here is my mini-proposal for what I think should be done (and what I would honestly like to do myself).

First, in parallel, support for Apache-based authentication and a native user group/role system need to be implemented. As soon as MT begins allowing in users that did not previously exist internally, the need for a default user configuration becomes apparent. While implementing that as a default set of permissions is an option, it can become a signifcant problem if and when changes to those default permissions need to be changed either for one individual user or for all users. In a small enough installation, it is workable, but in larger organizations being limited to only a single set of default permissions is not going to be an option. All of those problems are avoided by implementing a native group/role system, as one group can be designated as the default group and overall changes can be made to that group to affect everybody, as well changes to individual users can be made without affecting any other group member. In addition, it also sets the stage for the next step.

Finally, support for authentication directly from systems like LDAP/ADS and so forth can be implemented. With the group/role system already implemented, as backend support for external usernames and passwords is added, adding it for the external groups/roles should be relatively simple.

Those are just my thoughts at least. I have already just about implemented the Apache-based authentication, though without any kind of default permissions. I suppose a quick hack could be developed to support that.

And as a bit of an addendum to that, I should also mention that if something like this moves forward, MT will need to move to a more true session handling approach, as opposed to storing the username and password of the current user in a cookie. If nothing else, the group affiliations will need to be cached somewhere else the authentication server will be getting hammered.

Well, I just finished my initial testing and everything is working just wonderfully. Hopefully I will have things cleaned up and packaged nicely very soon. The External-Auth "plugin" will allow MT site administrators to use Apache's robust built in authentication mechanisms to give people access to MT. For example, I've logged into MT tonight via the following setup in Apache with mod_auth_pgsql :

AuthType Basic
AuthName "Rayners MT Install"
Require valid-user
Auth_PG_host localhost
Auth_PG_port 5432
Auth_PG_user mt_auth
Auth_PG_pwd  password
Auth_PG_database  access_control
Auth_PG_pwd_table mt_auth
Auth_PG_uid_field username
Auth_PG_pwd_field password
Auth_PG_hash_type md5

So, by adding a user into the user table in my access_control database and assigning the right permissions (in this case, in my system_user_access table), which makes the user visible in the mt_auth view, I could give this user access to MT without:

• Manually adding them to the MT system
• Having to maintain two passwords (or more if other systems are involved)

This currently does involve a minor edit to any MT application for which you would wish to use such an access control scheme (just adding/changing two lines). There probably is no way around that for the time being.

(One side note, as this will probably be not so useful for Joe Blogger, I will most likely make this available under a for-pay commercial-use license, but if there is enough interest, I am willing to consider a low-cost personal-use licence. No final decisions one way or the other have been made yet though.)