Remote
Authentication
IT UNIX Systems

Authenticating on a web server other than www.wsu.edu using the Network ID



It is possible for you to use your own web server, and redirect your cgi request to the www.wsu.edu   server to do your Network ID (kerberos) authentication, and then have the request redirected back to you as a confirmation that the client has been successfully authenticated.
caveat: You can only do this if your server is in the wsu.edu domain.
NOTE: Only faculty, staff, departments and student organizations are allowed to use this authentication facility. To register your script name to use authentication, go to registration.

The whole process works something like this: your browser contacts your host server, which contacts www.wsu.edu   to get a kerberos ticket; once a ticket has been obtained from www.wsu.edu , the key for that ticket is sent back to your host server indicating that the person has successfully logged on. Click on the thumbnail to the right to get an idea of the flow of processing.


The simplest way to do this is to create a script on my.server.wsu.edu   (lets call it "start.cgi") to call the script "remote_authenticate.cgi", which is already supplied for you on www.wsu.edu. You need to pass the parameter "return_url" from your start.cgi to remote_authenticate.cgi on www.wsu.edu   to let that script know where to return after the client has been successfully authenticated. Your script start.cgi could look something like this:


#!/usr/local/bin/perl
# start.cgi
#

print "Location: http://www.wsu.edu/cgi-bin/remote_authenticate.cgi?
  return_url=my.server.wsu.edu/cgi-bin/step3.cgi \n\n";

exit;

This is how it works: Your browser/client would send a connection request to your own web server, which we are calling my.server.wsu.edu   in this example.



The client then requests my.server.wsu.edu   to run the above script  start.cgi ;


The start.cgi calls the script remote_authenticate.cgi on www.wsu.edu   to do the kerberos authentication step. The script remote_authenticate.cgi is listed below. The first line brings in the wsumacs.pl macros. One of these macros is "&INIT_Script". This particular macro is used to check for kerberos Network ID (NID) authentication. It will translate the network id into a wsunumber and send that back to the return_url.

#!/usr/local/bin/perl
# remote_authenticate.cgi
#

$weblib="/usr/local/www/cgi-bin";
require "/cgi-bin/wsumacs.pl";

&INIT_Script;

$wsunumber = `$weblib/gwn $netid`;
print "Location: http://$FORM{return_url}?netid=$netid&wsunumber=$wsunumber\n\n";
exit;

To have the script use the secure socket layer so nobody sees the information going across the network, change "http:" above to "https:".

If the person running this script has not yet (or not recently) been authenticated, then the "&INIT_Script" macro will display the authentication screen where they can enter their NID and password. Click on the thumbnail to the right to see an example of the authentication screen.

After the NID and password are entered, they are brought back to the remote_authenticate.cgi script a second time as shown at the right.

 

The last time through, remote_authenticate.cgi will return to whatever URL you have specified with the parameter "return_url". In the above example from start.cgi we passed

return_url=http://my.server.wsu.edu/cgi-bin/step3.cgi

which means that the next program executed will be "step3.cgi" on my.server.wsu.edu. The step3.cgi script cold be instructed to send a page back to the client to be displayed on the browser.

 

Writing your own script on www.wsu.edu


If you don't want to use the provided remote_authenticate.cgi on www .wsu.edu, you can write your own script.

As before, you create a script on my.server.wsu.edu. For our example, lets call this script step1.cgi which is similar to the start.cgi from the above example. We need to have this CGI script point to www.wsu.edu   and to a CGI script of your own on that server. In this example, step1.cgi points to step2.cgi on the account "myown" on the www.wsu.edu   server. Here is what step1.cgi might look like:


#!/usr/local/bin/perl
# step1.cgi
#

print "Location: http://www.wsu.edu/~myown/cgi-bin/step2.cgi\n\n";

exit;


This is the sequence of events:

  1. your browser connects to my.server.wsu.edu
  2. requests to run the above script step1.cgi.
  3. calls step2.cgi on www.wsu.edu.
  4. does the authentication and passes back the person's NID to step3.cgi which is running on your my.server.wsu.edu.


The step1.cgi script on my.server.wsu.edu then calls the second script script2.cgi on www.wsu.edu. The serverwww.wsu.edu   is already setup to do kerberos authentication using the WSU Network ID (NID). The following illustrates the sequence of your browser calling my.server.wsu.edu, running step1.cgi, and then calling step2.cgi on www.wsu.edu   which will do the authentication.



On www.wsu.edu, your script2.cgi looks something like this:

#!/usr/local/bin/perl
# step2.cgi
#

require "/cgi-bin/wsumacs.pl";

&INIT_Script;

print "Location: http://my.server.wsu.edu/cgi-bin/step3.cgi?netid=$netid\n\n";

exit;


If the person running this script has not yet (or not recently) been authenticated, then the "&INIT_Script" macro will display the authentication screen where they can enter their NID and password. Click on the thumbnail to the right to see an example of the authentication screen.

 


After they enter their NID and password, the script step2.cgi is run a second time as illustrated in the picture to the right.

After the person has successfully logged in using their NID they will run the rest of the step2.cgi script. In particular, the statement:

print "Location: http://my.server.wsu.edu/cgi-bin/step3.cgi?netid=$netid\n\n";

This will execute the script step3.cgi which is in the cgi-bin directory on your web server my.server.wsu.edu. Notice that on the above redirect, the NID "netid" is passed from www.wsu.edu to my.server.wsu.edu so that your step3.cgi script can know the NID of the person logging in.



Here is a sample step3.cgi script. This gives a basic idea of some of the things you can do once the person has been authenticated.
caveat: This assumes you have installed your own copy of wsumacs on my.server.wsu.edu.


#!/usr/local/bin/perl
# step3.cgi
#


require "/usr/local/www/cgi-bin/wsumacs.pl";

&open_client;
&parseParms;
&parse_client_cookies;

%nid_auth_table = (
'guenther', 'level 1',
'nid2', 'level 2'
);

$netid = $FORM{netid};

if (!$nid_auth_table{$netid}) { # if the the nid isn't in our table
&netid_not_authorized;
}

if (length($COOKIES{KEY}) != 13) { # The key must be 13 characters long
&invalid_auth_request;
}

if (($COOKIES{kinit} ne "pending") && ($COOKIES{kinit} ne "done")) {
&invalid_auth_request; # the kinit value is one or the other
}

&print_header("Authorization Routine");
print CLIENT "Hello $netid!! You have been
successfully authorized with
$nid_auth_table{$netid} authorization.<p>\n";

&close_client;

exit;

sub netid_not_authorized {
&print_header("Authorization Error");
print CLIENT "This netid $FORM{netid} is not authorized to use this
cgi script!!";
exit;
}

sub invalid_auth_request {
&print_header("Authorization Error");
print CLIENT "This is an invalid request for this
cgi script!!";
exit;
}

The macro &open_client is used to open a socket to the client browser.

The macro &parseParms is used to parse the CGI parms sent from www.wsu.edu   to my.server.wsu.edu. Any CGI parms found are placed into the array FORM. In this case, there was one entry "$FORM{netid}" which was the value of the NID passed from step2.cgi to step3.cgi.

The macro &parse_client_cookies is used to parse out the cookies passed between the browser and the web servers. This was necessary to determine that

  1. the cookie called "KEY" was exactly 13 characters long, and
  2. the cookie "kinit" was either the value "pending" or "done".

Both of these conditions are necessary to have a valid authentication cookie.

The perl associative array $nid_auth_table is used to determine whether the NID being passed from step2.cgi to step3.cgi is authorized to run the step3.cgi script or not. The second value in this associative array ("level 1" for example) can be one way you can assign different authorization levels to different users. User "nid2" in the above example has an authorization level of "level 2". The user "guenther" has "level 1" authorization.

This user note is not intended to be a tutorial on perl. You can find out more about perl and CGI scripts at www.wsu.edu/UNIX_Systems/Chapters/www_tools.html.

You can also find out more about using the wsumacs.pl set of macros for your CGI scripts at www.wsu.edu/UNIX_Systems/cgi/wsumacs.html.

The result of running step3.cgi on my.server.wsu.edu is then sent back to the browser.

Which prints something like:

 

Logging Out

You should provide a mechanism for the person using your pages to be able to "logout" of your page and return to another page. This is a way you can destroy their kerberos ticket for them. You do this by calling the Logout.cgi script on www.wsu.edu. For example, if you wanted them to logout of your authenticated page and to go to the WSU home page you would say:

Press 
<A HREF=/cgi-bin/Logout.cgi?script=http://www.wsu.edu/> 
here to logout and go to the home page.</A>

That assumes your script already resides on www.wsu.edu. If the script resides on your own server, then you need to add the host name to the href:

Press 
<A HREF=http://www.wsu.edu/cgi-bin/Logout.cgi?script=http://www.wsu.edu/> 
here to logout and go to the home page.</A>


| Home | Search | Software List | IT Help Desk |

Questions and Help from: helpdesk@wsu.edu
Comments to: usgwww@wsu.edu .
Revised January 27, 1998. Copyright © 1996-1998 Washington State University.
URL: http://www.wsu.edu/UNIX_Systems

This page has been accessed times since January 27, 1998.