C2C transaction description

Some terms:

COD is our certificate-on-demand server.

Wd is our authentication broker.

Transaction flow:

  1. User asks for columbia.mascot.com page
  2. Server looks for cookie (I guess); seeing none, it sends a redirection to the user containing its url ("destinationurl"), url of a gateway cgi script at mascot ("gatewayurl"), and the actual redirection location, a cgi script at www1.
  3. Browser goes to cgi script at columbia with destinationurl and gatewayurl arguments.
  4. CGI script edits and sends back to the user a login form with hidden variables "destinationurl" and "gatewayurl".
  5. User enters user name and kerberos password and submits form to second cgi script at www1.
  6. Script uses geturl to access third script on www1 which has restricted access, using user's name and password. (Uses HTTP 'Basic Auth'.) htaccess file for this script will invoke wd with a certificate request.
  7. auth module for www1 checks user access to third script by forwarding user name, password, and cert req (a fixed spkac) to wd. The spkac is a "signed public key and challenge"; it is a fixed string in the htaccess because we never rely on the private key associated with these certs.
  8. wd verifies user name and password via kerberos.
  9. wd packages up complete cert req with Subject DN, validity times (5 minute validity), sends to COD> (After checking its local policy.)
  10. COD checks its local policy and sends back certificate.
  11. wd sends 200:ok and user cert to www1 auth module.
  12. 3rd cgi script gets cert out of environment and sends it back to geturl, where 2nd cgi script now has it.
  13. 2nd cgi script puts together redirection url with location=gatewayurl and cgi variables=destinationurl and certificate, sends 302 to berowser. This is an nph script (Apache allows this with https), so the script can send back its own 302 header.
  14. browser sends this to gateway cgi at mascot.
  15. gateway cgi script verifies: cert is signed by us, signature ok, first time seen, then digs user name out of cn part of dn, verifies it's a known user, sends cookie and protected page (="destinationurl") to user; user now logged in.