Creating a Drop-in Authentication Service for Movable Type



Summary

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.'


The User Experience

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 User Model

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:


Configuring Movable Type

An outside authentication system hooks into the Movable Type interface simply by using a handful of configuration options in mt.cfg. These are:


Parameters Passed by the Client

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.


Parameters for the Authentication Response

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.

Response Parameters in Version 1.1

Response Parameters in Version 1

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>


Format of the DSA key

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

Hidden email addresses

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.


Encoding Issues

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.


References

  • [1] Digital Signature Algorithm, <http://www.itl.nist.gov/fipspubs/fip180-1.htm>
  • [2] FIPS PUB 186, Digital Signature Standard, <http://www.itl.nist.gov/fipspubs/fip186.htm>
  • [3] FIPS PUB 180-1, Secure Hash Standard, <http://www.itl.nist.gov/fipspubs/fip180-1.htm>
  • [4] RFC 2045 - Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies (Section 6.8. describes Base64), <http://www.faqs.org/rfcs/rfc2045.html>
  • [5] Friend of a Friend project, <http://www.foaf-project.org/>

  • top