Summary of the idcheck cookie SSO

Overview

• idcheck is a cookie based single sign on technology. It is homegrown and hackable.
• The system installs a pair of cookies into the users browser. One of which is presented to the website they are attempting to access, the other is only made available to the central idcheck server. The cookie values are simply 32 digit random numbers which are presented to websites in a given domain.
• Webservers can be configured to to verify these cookies to determine who the owner is and if they are authorised to see the pages.
• The server has been implemented in mod_perl. With clients in C (for apache2), perl and PHP4.
• Currently idcheck is stable and in production use.
• The C client was written in the apache portable runtime api, therefore should build on all platforms that support apache2. So far this has been verified on Linux/Solaris and Netware.

A Simplified description of the idcheck2 algorithm.

Components:

• BROWSER: The users browser.
• ORIGIN_WEBSITE The website the user is attempting to access which has been configured to use the idcheck mechanism.
• IDCHECK_WEBSITE: A webserver which can authenticate a user and verify cookies for other webservers.
• LOGIN_FORM: A page on that presents a login form allowing the user to enter a username and password. The login form on IDCHECK_WEBSITE can be used but the form does not have to be hosted there.
• AUTH: An authentication source against which credentials can be verified (currently LDAP directories are supported).
• REQUEST_COOKIE: A cookie containing the URL the user was attempting to access (+ some other information).
• IDCHECK_COOKIE: A cookie containing a 32 digit random number, scoped only for the IDCHECK_WEBSITE.
• WEBSERVER_COOKIE: A cookie containing a 32 digit random number (the same value that is in the REQUEST_COOKIE), scoped only for the ORIGIN_WEBSITE.

Simplified User Login Sequence:

1. BROWSER attempts to access ORIGIN_WEBSITE.

2. ORIGIN_WEBSITE (via the idcheck module) looks for an idcheck cookie in the request. If it fails to find one idcheck module sets a REQUEST_COOKIE and redirects the browser to LOGIN_FORM on the IDCHECK_WEBSERVER.

3. The users browser now contains a LOGIN_FORM and they submit a username and password. This sumbitted request also contained a REQUEST_COOKIE which has not been validated yet. Successful completion of this form, sets a valid IDCHECK_COOKIE and registers the REQUEST_COOKIE as a valid cookie by associating it with the private IDHCECK_COOKIE value on the server and replacing its content with a 32 digit random number. Then the BROWSER is redirected back to the URL they were originally attempting to access.

4. ORIGIN_WEBSITE now sees that there is a validated REQUEST_COOKIE cookie present and checks its random value against IDCHECK_WEBSERVER (by a GET request over http). If that verification suceeds, IDCHECK_WEBSERVER returns the username and other authorisation data to the ORIGIN_WEBSITE. IDCHECK_WEBSERVER. The REQUEST_COOKIE is unset and the random value is installed in a WEBSERVER_COOKIE scoped only for the ORIGIN_WEBSITE. The WEBSERVER_COOKIE is used to authenticate future visits in the same way as the REQUEST_COOKIE

5. ORIGIN_WEBSITE now examines the data strings supplied by the idcheck cookie and its own rulesets to decide if it should allow that user access to the URL they requested. If access is permitted, then the page is sent back to BROWSER. If they are not, then they are redirected to a page informing them that they do not have sufficient authorisation to access the requested page.

6. If the BROWSER attempts to access a second ORIGIN_WEBSITE, REQUEST_COOKIES are installed and the browser is redirected to the LOGIN_FORM (as per above). However, this time the LOGIN_FORM request contains a private IDCHECK_COOKIE which the IDCHECK_WEBSERVER uses to authorise the REQUEST_COOKIE and immediatly redirect back to the second ORIGIN_WEBSITE. Thus the user gets to the second ORIGIN_WEBSITE transparently (and picks up a cookie for that site on the way).

The end user experience is that they click on a URL that they want to access, they are presented with a login form, they submit the form and get the URL they were requesting - about as simple as can be.

Example "client webserver" Configuration (the C version):

  # load the module
  LoadModule mod_idcheck.c

  IdcheckLoginUrl https://idcheck.some.domain/idcheck
  IdcheckCheckUrl http://idcheck.some.domain/idcheck

  # A simple idcheck protected url
  <Location /protected>
    AuthType idcheck
    Idcheck on
    IdcheckNoAccessBehaviour server
    Require valid-user
  </Location>

  # the information page (also protected)
  <Location /idcheck-info>
    SetHandler idcheck-info
    AuthType idcheck
    Idcheck on
    Require valid-user
  </Location>

  # locations that allows only computing services and user abc123.
  <Location /protected/css_only>
    IdcheckAllowData "staff:unit=Computing Services"
    IdcheckAllowUser abc162
  </Location>

  # a basic only protected location underneath an idcheck protected location.
  <Location /protected/basic>
    Idcheck off
    AuthType Basic
    AuthName "Basic realm"
    AuthUserFile /etc/httpd/conf/test-basic.passwd
    Require valid-user
  </Location>

  # access by IP address, by non-authoritative idcheck
  # or by authoritative basic. i.e. a basic auth dialog box
  # is displayed if there is no access.
  <Location /id_or_basic>
    # allow by IP
    Order deny,allow
    Deny from all
    Allow from 127.0.0.99

    # allow by idcheck
    Idcheck on

    AuthType Basic
    AuthName "Basic realm"
    AuthUserFile /etc/httpd/conf/test-basic.passwd

    Require valid-user
    Satisfy any
  </Location>

These directives can also be placed into .htaccess files. These directives are also subject to change.