With the release of MovableType 3.0D, SixApart published this document on how to use TypeKey in other applications. I was more interested in how to use MovableType with other authentication systems. I’ve implemented my own system that you can use with MoveableType instead of TypeKey. This means you don’t have to use the centralized authentication servers and you will be able to set up your own registration system.
First, lets take a look at how TypeKey works.
–Public and Private Keys–
SixApart’s TypeKey server use a 512 bit DSA key pair. It isn’t clear to me why they went with a 512 bit key instead of a more secure 1024 bit one. 512 should be enough and results in a smaller public key file thus reducing bandwidth.
TypeKey uses a strange format for the public key that looks something like this:
p=8155234902018568264091686597921939014512021837970421263461600358
933662856688191461459392075903358241817981959216328775566620722022
975741189395165871826229 g=323429242208031341480745147369524111345
511032626221371401040590275045682199023762665524572015263249749391
056421424904190382407356015141120805061722765326 q=870366094440870
827262403490098464954086432367287 pub_key=153056137722087555496598
4281622213958422101270825619941483077854055912940728234783432336
Their key can be found at http://www.typepad.com/extras/regkeys.txt.
Their public key format includes the p, q, g, and pub_key variables in decimal. These are all variables involved with generating the keys. Information on how DSA key generation works can be found here. I think it would have made more sense to use a standard key format like PEM instead of their own, but maybe it is easier to read and parse in Perl.
The private key is, well, private so it can be stored any way you want. I don’t know how TypeKey stores their private key, but it isn’t really important.
———————————————-
–User Authentication–
Step 1: Sign in
The signin URL looks something like this: https://www.typekey.com/t/typekey/login?&t=twGk5EFQJsxQ2t4bGXhK&_r
eturn=http://www.pavlov.net/mt/mt-comments.cgi%3f__mode=handle_sig
n_in%26static=1%26entry_id=355
Lets break this URL down in to parts.
https://www.typekey.com/t/typekey/login is the URL defined by the ‘SignOnURL‘ variable inside lib/MT/ConfigMgr.pm in your MT installation.
t=twGk5EFQJsxQ2t4bGXhK is your TypeKey site token. This is whatever you have entered in Weblog Config/Preferences/TypeKey Token.
_return=http://www.pavlov.net/mt/mt-comments.cgi%3f__mode=handle_s
ign_in%26static=1%26entry_id=355 is the URL that TypeKey should redirect to after it has authenticated you.
On the login page, it has a form with username and password fields. It also has links to register and a link incase you forgot your password. The form also has hidden inputs to pass along the ‘__mode’, ‘_return’ and ‘t’ parameters. Once the user hits the ‘Log In’ button, all the interesting stuff happens.
Step 2: User verification
When the submit happens, it does a HTTP POST to the form action passing along ‘__mode’, ‘_return’, ‘t’, ‘username’ and ‘password’.
At this point, there is no way for me to know exactly what TypeKey does internally, but I can talk about what my implementation does.
I start off by doing a SQL query looking for a row where the username column is the username passed in. This looks something like: select * where username = $username. If a result comes back, then it verifies the password passed in with that in the database. If that matches, you can go right on to generating a TypeKey response.
Step 3: The Response
The TypeKey response includes 4 fields about the user plus a DSA signature. The users email address, a unique login name, a nickname (the user’s “display name”) and a timestamp. The email address, login name, and nickname all come from the database, and the timestamp is the current time
In order to generate a signature, the server must generate a string that looks like:
<email>::<name>::<nick>::<ts>
For example: p@p.net::pavlov::Pavlov::1086688418
Once it has that string, it needs to get the SHA1 digest of the string and then sign it with the private key. Signing will give you a signature which is made up of 2 numbers: r and s. Instead of using decimal numbers like the public key uses, it uses the numbers in big-endian form. It then base64 encode each one variable seperatly. Now the server has r-base64 and s-base64. All of the data required for the response is known at this point.
The server now has an email address, login name, display name, timestamp, r-base64 and s-base64 variables. At this point it can redirect back to MovableType. The ‘_return’ variable that was saved off on the login page is the base URL that it redirects to. A few paramters need to be put on to the end of the return address. These are:
email=<email>&name=<name>&nick=<nick>&ts=<timestamp>&sig=<r-base64>:<s-base64>
So we send a Location: header that looks something like this:
http://www.pavlov.net/mt/mt-comments.cgi?__mode=handle_sign_in&sta
tic=1&entry_id=355&email=p@p.net&name=pavlov&nick=Pavlov&ts=108668
8418&sig=VMwm9QnQCpV31bDdRYoteFVOANo=:DO+Ob3Lp8aEzw7FuJvDdogU5nHY=
At this point some cookies will get set on the client and the user will be logged in and able to post a comment on the blog.
———————————————-
– Sign out –
For signing out, the logout page just needs to redirect the user back to the ‘_return’ parameter.
———————————————-
I’ll post more details on how exactly my replacement system works in the next day or two.
