cosign wiki:CosignCGIs
From cosign wiki
(→Dynamic Pages) |
Current revision (12:42, 21 September 2010) (view source) (Reverting spam yet again.) |
||
| (200 intermediate revisions not shown.) | |||
Current revision
Contents |
Cosign CGIs
Cosign has two CGIs: cosign.cgi and logout.
cosign.cgi
cosign.cgi, the "login" CGI, is responsible for logging users into and out of the central Cosign server. It is also responsible for registering each service a user logs into; this action ties the user's central login cookie to their session on individual application servers, such as a web mail client, web directory client, or CourseTools environment. The prototype CGI was built to use Kerberos V/GSSAPI to authenticate the user. Guest accounts via Cosign Friend and a MySQL database are also supported, as is authentication with Apache's BasicAuth and x.509 certificates. Cosign 2.x supports external authenticators with a new API, which enables the CGI to use an arbitrary login method by calling out to an external program.
The CGI also has the ability to prompt the user to re-enter their password in order to access any service that has registered for re-authentication. This means that before the CGI will REGISTER a service cookie for a service configured for re-authentication, the user must successfully authenticate again. This is considered more secure and gives a slightly better assurance that users are in fact who they claim to be.
Logout
The logout CGI is responsible for logging users out of the central cosign server. Once a logout has been verified, the logout CGI clobbers the login cookie by writing a cookie with the value null and setting the cookie's expiration date to a time in the past. Since all state is maintained centrally, the user is immediately logged out of all applications visited during the current session, with one notable exception:
Due to the implementation of data caching in the filters, the most recent application a user has visited will still report the user as being logged in for the duration of cache time (default is 60 seconds). In order to avoid this lag, a local logout script can be run on the application server to expire the local cosign-service cookie. This marks the user as logged out locally and can then redirect the user to the central logout script. After the logout has been verified, the user is truly logged out of all Cosign-protected services.
CGI Templates
The templates used by Cosign CGIs fall into two broad categories: dynamic and static.
Dynamic Pages
The tables below list the required fields for dynamically-generated Cosign pages. They are dynamic in that the variable $l in the template for reauth.html will be replaced by the CGI with the login name of the currently logged-in user. Fields like verify in verify-logout.html are required, but their value can be determined on a per-installation basis.
| Page Name | login.html | ||
| draws the login screen for initial logins using cosign.cgi | |||
| Method | post | Action | /cosign-bin/cosign.cgi |
| Value | Form Field Name | Description | |
| $t | the page title, e.g. CoSign: $t | ||
| $r | ref | URL to redirect upon successful login | |
| $c | service | the service cookie received on the query string | |
| $f | required | required factors from filter via query string | |
| $d | required factors already satisfied via CHECK | ||
| $l | login | the user id of the person attempting to login | |
| password | field for user to enter their password | ||
| Page Name | error.html | ||
| reports any non-retryable errors from cosign.cgi | |||
| Method | n/a | Action | n/a |
| Value | Form Field Name | Description | |
| $t | the page title, e.g. CoSign: $t | ||
| $e | field to print relevant error message | ||
| Page Name | login_error.html | ||
| draws login screen when a retryable error is encountered by cosign.cgi | |||
| Method | post | Action | /cosign-bin/cosign.cgi |
| Value | Form Field Name | Description | |
| $t | the page title, e.g. CoSign: $t | ||
| $r | ref | URL to redirect upon successful login | |
| $c | service | the service cookie received on the query string | |
| $f | required | required factors from filter via query string | |
| $d | required factors already satisfied via CHECK | ||
| $l | login | the user id of the person attempting to login | |
| password | |||
| $e | field to print relevant error message | ||
| Page Name | verify-logout.html | ||
| draws logout confirmation screen | |||
| Method | post | Action | /cosign-bin/logout |
| Value | Form Field Name | Description | |
| $t | the page title, e.g. CoSign: $t | ||
| $u | url | URL to redirect upon successful logout | |
| Logout | verify | submit button | |
| Page Name | reauth.html | ||
| draws login screen for re-authentication | |||
| Method | post | Action | /cosign-bin/cosign.cgi |
| Method | post | Action | /cosign-bin/logout |
| Value | Form Field Name | Description | |
| $t | the page title, e.g. CoSign: $t | ||
| $r | ref | URL to redirect upon successful login | |
| $r | url | URL to redirect upon successful logout | |
| $c | service | the service cookie received on the query string | |
| $f | required | required factors from cgi’s reauth config | |
| $l | login | the user id of the person attempting to login | |
| password | field for user to enter their password | ||
| true | reauth | flag for CGI | |
| true | verify | flag for CGI | |
Static Pages
The following pages are required by cosign.cgi but have no dynamically-generated content:
- post_error.html – The filter will redirect users to this page should a REGISTER be required during a POST. Cosign does not currently support REGISTERing through a POST, and as such, a user’s data would be lost. Instead, the user sees a splash page that tells them that their changes were not saved, informs them of ways to avoid the problem in the future, and gives a link to the login page.
- looping.html – The cosign.cgi CGI redirects a user to this page when a browser loop is detected. These are caused by ill-configured filters or badly-behaving browsers. This page has some helpful text to inform the user of possible causes of the loop and how to contact support staff.
- /services/ – By default, a successful login with no referrer destination URL will be redirected to https://weblogin.example.com/services/. This is called the “service menu” and it is an ideal jumping-off point for listing your institution’s Cosign-protected services.
More information:
--John 16:50, 14 November 2006 (EST)
