Welcome to idcheck!
idcheck is a Single Sign On (SSO) mechanism.
The way it works is fairly simple. The first time a user attempts to download a page from a webserver with mod_idcheck.so installed, it redirects the request to the idcheck server. The idcheck server serves a login page and then checks the submitted credentials against an LDAP server. If successful, the user is redirected back to the page they requested. As it redirects, the server installs a private cookie (scoped only for the idcheck webserver) and a second cookie that acts as a session cookie for the content webserver. When the users web browser connected to the content server again the idcheck cookie (for that webserver alone) is checked for validity (by the webserver against the idcheck server by mod_idcheck.so). If successful, the content can then be downloaded.
When the user accesses another webserver that also has idcheck restricted pages he does not need to enter his credentials again because the private idcheck cookie that he already posesses shows that he is already authenticated and so can bypass the login form. This provides a SSO environment for multiple webservers in a single DNS domain. The client browser gets a few 302 redirects but its otherwise transparent.
The mechanism has several features. Firstly, the central idcheck cookie, normally negotiated over https is only made available to the idcheck server itself over https. Each separate content hosting server (apache+mod_idcheck.so) only sees an idcheck cookie that works with it. Each content hosting server gets a separate cookie which is distinct from the cookie that the idcheck server sees and cannot be used to gain access to another webserver - only the idcheck cookie allows that.
Secondly, because the cookie on the content hosting webserver only allows access to that server web server administrators can make a decision about if they wish to install SSL certificates on that server or not. If, for example, the server is an intranet server viewed by a large organisation with thousands of people (then its content isnt really a big secret as its content will be vetted and filtered by a Communications department and most of the users will show someone the intranet page anyway) then it probably does not really need an SSL certificate.
However, if SSL is essential, idcheck can also be fully configured that way.
Website administrators are free to make these choices on a per-site basis rather than having to buy an SSL cert for every webserver they have.
In addition, The mechanism provides detailed, filtered, data about the user to other webservers so that they can make fine grained authorisation decisions. For example, with idcheck and a suitable authentication source (e.g. an LDAP server - OpenLDAP or Active Directory) it is possible to restrict certain areas of websites to individuals or groups of individuals (e.g. those in the same department or building). That granularity only depends on the granularity of the data in your LDAP server.
The mechanism has been implemented using the standard apache httpd login hooks. This means that any website or application that supports say HTTP Basic Auth can be configured to use idcheck.
It is quite common for people to install mod_idcheck.so on a PHP webserver with a particular application installed. Find the login PHP part of the application and modify it to just check for the presence of an apache REMOTE_USER environment variable.
The mechanism also supports a logout URL. e.g. http://idcheck.example.com/idcheck?do=logout
Users can check their own idcheck data with the URL http://idcheck.example.com/idcheck?do=info
Various articles are available by clicking on on "Browse Pages" or "Browse Labels" buttons (on the left).
There is an idcheck web page at http://idcheck.sourceforge.net. The info on this page is a little old and I will be moving stuff into this wiki.
The idcheck server has quite alot of documentation built in as perldoc. This can be viewed with this command.