Difference between revisions of "External (Cosign) Authentication"

From WeBWorK_wiki
Jump to navigation Jump to search
(New page: WeBWorK 2.3 contains support for authenticating WeBWorK logins against Cosign, or another external (web-server based) authentication system. == Background == [http://www.umich.edu/~umweb...)
 
m
Line 9: Line 9:
 
== Using Cosign with WeBWorK ==
 
== Using Cosign with WeBWorK ==
   
To use cosign with WeBWorK, we use the Authen::Cosign WeBWorK module, and tell WeBWorK that the WeBWorK directories are cosign protected. This requires adding an <code>.htaccess</code> file to the protected directories, or adding a new <code>Location</code> stanza to the web server's configuration file. For example,
+
To use cosign with WeBWorK, we use the Authen::Cosign WeBWorK module, and tell the web server that the WeBWorK directories are cosign protected. This requires adding an <code>.htaccess</code> file to the protected directories, or adding a new <code>Location</code> stanza to the web server's configuration file. For example,
   
 
<pre>
 
<pre>

Revision as of 10:16, 10 March 2008

WeBWorK 2.3 contains support for authenticating WeBWorK logins against Cosign, or another external (web-server based) authentication system.

Background

Cosign (Collaborative single-sign on) is an open source project originally designed to provide the University of Michigan with a secure single sign-on web authentication system. It is part of the National Science Foundation Middleware Initiative (NMI) EDIT software release.

Cosign works as a filter in the web server: that is, a resource is designated for the web server as being cosign protected, and the web server then checks with the central cosign server to verify if the user is authenticated before allowing access to the resource. In this manner it is similar to HTTP BasicAuth, but it differs significantly in that it is actually secure.

Using Cosign with WeBWorK

To use cosign with WeBWorK, we use the Authen::Cosign WeBWorK module, and tell the web server that the WeBWorK directories are cosign protected. This requires adding an .htaccess file to the protected directories, or adding a new Location stanza to the web server's configuration file. For example,

<LocationMatch "/webwork2/math-[0-9]+">
    CosignProtected     On
    CosignHostname      cosignhost.domain.edu
    CosignRedirect      https://cosignhost.domain.edu/
    CosignPostErrorRedirect https://cosignhost.domain.edu/cosign/post_error.html
    CosignService     webservername
    CosignCrypto      /location/of/server/ssl.key /location/of/server/server.crt /location/of/cosign/CAcerts/
</LocationMatch>

This results in all course addresses /webwork2/math-XXX, where XXX are numerical digits, requiring that the user authenticate through cosign before the webserver will allow access to them.

Then, in the WeBWorK global.conf file, or in the applicable course.conf files, we specify cosign authentication:

  $authen{user_module} = "WeBWorK::Authen::Cosign";

Class Rosters When Using Cosign

Note that cosign manages authentication, not authorization. The WeBWorK class roster is still used for cosign protected resources to determine if the user is in the correct class and whether the user is a professor, T.A., or student. In addition, note that proctor authentication for proctored gateway/quiz assignments is still done through WeBWorK. There is a good technical reason for this.

Excluding Classes from Cosign

If $r->ce->{cosignoff} is set for a course, authentication reverts to standard WeBWorK Authentication. Thus, if $authen{user_module} = "WeBWorK::Authen::Cosign"; is set in the global.conf, we want to set $cosignoff = 1; in the course.conf file of any course that isn't described by the cosign Location stanza in the web server's configuration file.


Credits

Gavin LaRose wrote the WeBWorK::Authen::Cosign module, based on existing WeBWorK authentication modules.