Hey all,
I've been working on a flow diagram, similar to what exists on http://weblogin.org/overview.html,
to outline the new work flow of Cosign 3.0.x. I'm looking for any
feedback y'all may have -- anything I can be more specific on? Anything
in the description or diagram that is just plain wrong?
The 3.0.x flow diagram is available at: http://people.brandeis.edu/~jwest/cosign/cosign-flow.png
And the instructions for the associated steps are as follows:
- User visits the protected service, https://service/securepage, in a
web browser.
- The Cosign filter, such as a module to Apache or IIS,
recognizes the visitor has not yet logged in through Cosign because no service
cookie was sent. Their browser is instructed to visit the
login site, referred to as Weblogin in the above
diagram.
- Browser follows the redirection instruction sent from
step B.
- Browser requests Cosign login page from the Weblogin
server and supplies
GET variables of:
-
Factors: Authentication factors the protected
service has specified it requires (CosignRequireFactor).
-
Service: Name of the protected service
according to Cosign (CosignService).
-
Source: URL of the service redirecting the
browser to Weblogin site.
- Browser is presented with HTML of the login page.
Additionally, a cookie is set to uniquely identify the user. This is
referred to as the login cookie.
- User fills out the login form with their credentials,
such as username and password, and
POST's results to the Weblogin
CGI.
- The Cosign CGI, hosted on the Weblogin
server, receives the results of the HTTP
POST.
- The CGI retrieves the Kerberos V ticket from the configured
KDC for the principal (user).
- If the ticket is retrieved, it is stored in the
/var/cosign/ticket
directory.
- The CGI then contacts the Cosign daemon running locally
(tcp/6663) and initiates, for each factor:
-
CHECK command.
-
LOGIN command.
- The CGI then initiates the
REGISTER
command, to register the user's login cookie with the
service.
- User is then redirected to the Cosign validation URL
configured for that service. Generally, this is https://service/cosign/valid.
- Browser, as per the Location redirect in the above
step, navigates to the validation URL
- If the user visits the appropriate validation URL,
the Cosign filter (e.g. mod_cosign) intercepts this call. It initiates
an out of band communication with the
cosignd (tcp/6663
by default) on the Cosign server to CHECK the service
cookie and retrieve additional information, such as the user's
username.
- If the service cookie is valid,
cosignd
returns OK.
- mod_cosign records the service cookie
and associated information about the user in
/var/cosign/daemon.
- mod_cosign redirects the user to the original protected
page they tried to access. Additionally, it sets the service
cookie within the user's browser.
- The browser requests the original protected page and
passes the service cookie along with the request.
- The web server responds with the HTML of the protected
resource.
The above instructions assume that:
- 'cosigndb' directory is set to "/var/cosign/daemon"
- 'cosignticketcache' directory is set to "/var/cosign/ticket"
Any questions, just let me know.
Thanks.
--
Joshua West
Senior Systems Engineer
Brandeis University
http://www.brandeis.edu
|
------------------------------------------------------------------------------
Register Now & Save for Velocity, the Web Performance & Operations
Conference from O'Reilly Media. Velocity features a full day of
expert-led, hands-on workshops and two days of sessions from industry
leaders in dedicated Performance & Operations tracks. Use code vel09scf
and Save an extra 15% before 5/3. http://p.sf.net/sfu/velocityconf
_______________________________________________
Cosign-discuss mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/cosign-discuss
