cosign wiki:SSO Scheme
From cosign wiki
(→More information:) |
|||
| Line 5: | Line 5: | ||
These pages are based on the document ''[http://www.umich.edu/~umweb/software/cosign/media/cosignscheme2006a.rtf The Cosign Web Single Sign-On Scheme]'', June 2006, Draft 4, by Craig, Craig, McGowan, and Malestein, with assistance from Cory Snavely. | These pages are based on the document ''[http://www.umich.edu/~umweb/software/cosign/media/cosignscheme2006a.rtf The Cosign Web Single Sign-On Scheme]'', June 2006, Draft 4, by Craig, Craig, McGowan, and Malestein, with assistance from Cory Snavely. | ||
| - | + | == Authentication Sequence (Overview) == | |
| - | + | The process begins when the user accesses an area on the web server for which the filter is configured to require authentication. The filter checks for the presence of a valid service cookie, and if one is not present, it sets a new one and redirects the user's browser to the Cosign CGI, including the service cookie and a return URL in the query string. | |
| + | |||
| + | The Cosign CGI, in turn, checks for the presence of a valid login cookie. If present, the CGI registers the new service cookie with the existing login cookie, and redirects the user's browser back to the return URL; this is ''single sign-on'' in action, permitting authentication to multiple applications and resources without additional password prompting. If the login cookie is not present, however, the Cosign CGI presents an authentication form, and upon successful authentication, creates the login cookie, registers the service cookie with it, and redirects the user's browser to the return URL. | ||
| + | |||
| + | When the user's browser returns to the application, the filter again checks for and locates a valid service cookie. The filter then populates the environment with the user’s authentication information and permits access to the application. | ||
| + | |||
| + | == More information: == | ||
| + | [[Cosign_Wiki:CosignCookies|Cookies]] | ||
| + | |||
| + | [[Cosign_Wiki:CosignFilter|Filter]] | ||
| + | |||
| + | [[Cosign_Wiki:CosignCGIs|CGIs]] | ||
| + | |||
| + | [[Cosign_Wiki:CosignDaemons|Daemons]] | ||
| + | |||
| + | |||
| + | --[[User:Jd@bnl.gov|John]] 16:13, 14 November 2006 (EST) | ||
Revision as of 14:05, 3 September 2014
Introduction
This series of pages presents the overall design scheme of Cosign, an open source, single sign-on, web package. It describes the functionality of the three major parts of Cosign: the filter, the CGIs, and the daemons. Also described are Cosign's supporting components, including cookie values, the query string protocol, template structure, local cookie cache file formats, and the SMTP-like, SSL-encrypted Cosign Protocol, which the filters and CGIs use to communicate with the daemon.
These pages are based on the document The Cosign Web Single Sign-On Scheme, June 2006, Draft 4, by Craig, Craig, McGowan, and Malestein, with assistance from Cory Snavely.
Authentication Sequence (Overview)
The process begins when the user accesses an area on the web server for which the filter is configured to require authentication. The filter checks for the presence of a valid service cookie, and if one is not present, it sets a new one and redirects the user's browser to the Cosign CGI, including the service cookie and a return URL in the query string.
The Cosign CGI, in turn, checks for the presence of a valid login cookie. If present, the CGI registers the new service cookie with the existing login cookie, and redirects the user's browser back to the return URL; this is single sign-on in action, permitting authentication to multiple applications and resources without additional password prompting. If the login cookie is not present, however, the Cosign CGI presents an authentication form, and upon successful authentication, creates the login cookie, registers the service cookie with it, and redirects the user's browser to the return URL.
When the user's browser returns to the application, the filter again checks for and locates a valid service cookie. The filter then populates the environment with the user’s authentication information and permits access to the application.
More information:
--John 16:13, 14 November 2006 (EST)
