Movable Type 3.0 provides a new suite of features for comment management, and part of that suite is an interface for authenticating users via an outside system. Six Apart's own TypeKey system is an example authentication system, but others can be made to interact with Movable Type.
For developers who wish to develop a custom authentication service to replace TypeKey, this document specifies the interface.
The heart of the system is based on digital signatures using the Digital Signature Algorithm [1] and the SHA1 hash function. The authentication service has a private key, and the MT installation has the corresponding public key available. Once the authentication service has authenticated a user, it passes the user's profile information, together with a digital signature of that information, to the MT installation. MT verifies the signature using the public key, and if it is correct, it sets a browser cookie so that it can identify the user again.
To create an alternate authentication service, you need to create a set of HTTP handlers that follow the calling conventions below. To use an alternate authentication service, you need to configure the MT parameters described under `Configuring Movable Type.'
Typically, the user starts at an MT comment page
!TBD!
MT comment page -> Authentication login -> Authentication registration -> MT comment page -> Authentication logout -> MT comment page
The authentication service should store data for a collection of users
who are identified by a unique key, known as the name. The name is
a textual value of no more than 50 characters, encoded in ASCII in the
character set [A-Za-z0-9_]. It should also store, for each user, at
least the following fields:
An outside authentication system hooks into the Movable Type interface simply by using a handful of configuration options in mt.cfg. These are:
MT will append a CGI parameter _return whose value is the URL to
return to once the log in is completed. The _return parameter
points to an MT handler which will decode a DSA signature [2] passed
by the authentication service. The arguments which the auth service
needs to pass are documented below, under Parameters for the Authentication Response.
logout link on a commenting page. The authentication
service is expected to do whatever is necessary to reset that user's
browser to a logged out state, and redirect to the value of the
_return parameter.
The value loaded from this URL is cached by MT for 24 hours.
<IdentityURL>/<username>
where <username> is the the unique key of the user, which is taken
from the name parameter supplied by the authentication service (see
Parameters for the Authentication Response, below);
When creating the user link to the authentication service, Movable
Type will include a CGI parameter with the name v, which identifies
the version of the protocol that it expects the service to use. If
this parameter is not given, it should be assumed to have the value 1.
It is acceptable for the service to refuse to support requests for sufficiently old versions of the TypeKey protocol, however, older versions of Movable Type still in use may then be unable to use the service.
When the authentication service has authenticated a user, it redirects
the browser to the _return address, with some additional CGI
parameters appended. The parameters are determined by the version of
the protocol passed by the client in the CGI parameter v, which
should be considered to have the value 1 if it is not passed.
sig parameter is
formed by concatenating the base64 representation [4] of r and s,
joined by a colon:
<r-base64>:<s-base64>
The ``message'' to be signed by the authentication service is a string formed by concatenating several values, separated by double-colons (``::'').
<email>::<name>::<nick>::<ts>::<site token>
All of these values are also given in the cleartext of the response (as above) except for the site token, which was passed by the client. For example, If I was ``Napoleon Bonaparte'' <napoleon@france.fr> with a login name of 'napster', and I logged in at 2001-09-08 19:00:00 (or 1000000800 seconds from the epoch), sig would be the signature for this string:
napoleon@france.fr::Napolon Bonaparte::napster::1000000800::6jTGQ2MF1focBR5vODfC
Version 1 of the protocol is exactly as specified for version 1.1, except that the site token is not included in the response signature. The value which is passed to the DSA algorithm is thus:
<email>::<name>::<nick>::<ts>
A public key for the Digital Signature Algorithm consists of four fields: p, q, g, and pub_key. When MT searches for a DSA key, it expects the four fields to be given in decimal, on one line of text, separated by whitespace. The fields are separated from their names by a '=' character. For example:
p=11671236708387678327224206536086899180337891539414163231548040398520841845883184000627860280911468857014406210406182985401875818712804278750455023001090753 g=8390523802553664927497849579280285206671739131891639945934584937465879937204060160958306281843225586442674344146773393578506632957361175802992793531760152 q=1096416736263180470838402356096058638299098593011 pub_key=10172504425160158571454141863297493878195176114077274329624884017831109225358009830193460871698707783589128269392033962133593624636454152482919340057145639
MT3 has a feature to allow authentication services to protect commenters' email addresses while still providing identity for those people. When this feature is used, the authentication service doesn't pass email addresses to MT, but instead passes a value that is computed from the email address by a one-way hash function.
Let's use an example. You're using an authentication system that isn't passing Luke's email address to you. A commenter comes to your site who you don't know, and uses the name 'Luke Skywalker.' After reading the comment, you decide it is relevant to the discussion and you approve him. Some time later you see another comment, which is malicious and off-topic, bearing the name Luke Skywalker. Is this the same person? To find out, you go into the ``Comments'' screen in Movable Type, and find the recent comment by ``Luke Skywalker.'' To search for all comments by that particular user, you just click the magnifying-glass icon next to his name. He may have used a different name at some time, but nonetheless all comments posted by that account will appear as the result of this search.
Now suppose that someone named Grover has posted on your site and you want to know if that's your friend grover@sesamestreet.com. You can type that email address into the search box on the comment screen, and it will even find the comments of his where his email address is hidden.
It's a lot like magic, but it's possible because of a one-way mathematical 'hash' function which hides the email address while still making it searchable.
When this feature is used, the value passed is the same as the value used in FOAF files [5], so you can also determine whether a commenter is the same person identified by a given FOAF file.
Specifically, the hashed email address is formed by prepending
mailto: to the address and hashing the result.
The nick field stored by the service will be displayed by Movable
Type in HTML pages, and may include encode characters from a very
large set. Since the target pages (generally, weblogs) may be use a
variety of encodings, which are not known to the authentication
service, the safest practice is to encode the nick field with HTML
entities.
The nick CGI parameter in the authentication response must be
byte-for-byte identical to the value used to compute the
signature. Aside from URL-decoding the query string, Movable Type will
not do any re-coding when verifying the signature.
However, the nick value is not restricted to the US-ASCII character
set, and authentication services are free to assume a particular encoding
if desired.