Logging in as an instructor without the password

Some operations, such as gradebook operations, can only be performed by instructors. This can be a problem for third party applications that need to perform gradebook operations without having to keep track of login information for all instructors.

PowerLinks SDK 2.0 (released with Vista 3.0) provides a solution that allows third party application to log in as course instructors without knowing their passwords: the proxy login.

Proxy login consists of retrieving the list of instructor IDs for a course section and then logging in as one of them using a special login method. This login method does not take a username/password combination. Instead, it calls an authentication module to authenticate the request and returns a valid session that can be used to perform operations with the same permissions as the instructor.

Getting Instructor IDs

The first step is to get the LCID of the section. The ContextSDK.getLearningContextIdByPath()is an easy way to get an LCID. It takes a session and a string containing the hierarchical path to the section. (The path must begin with the group.)

Next, you need to get the instructor person IDs for the section. The ContextSDK.getInstructorPersonIDs() method returns an array containing the person IDs of the instructors. Note that you must be enrolled as an institution administrator in order to use this method.

Here is an example:

try
{
// log in as an institution admin
ContextSDK ctxt = new ContextSDK(soapSvrURL);
SessionVO admSession = ctxt.login(adminUser,adminPassword,glcid);

// the path from the group down to the section
String path = "SDK Group/SDK Course/SDK Section";
long lcid = ctxt.getLearningContextIdByPath(admSession,
path);

// get instructor IDs for that section
long\[\] personIds = ctxt.getInstructorPersonIDs(admSession,
lcid);
}

Logging in via Proxy

The next step is to call the proxy login method, ContextSDK.login(authModuleGroupName, lcid, settings), to login as the section instructor. The parameters for this method are:

authModuleGroupName - the group name of the authentication module you want to use to authenticate the proxy login request. It should be in the format of /DeployableComponents/<setting_group_name>. The setting_group_name is the value in the <setting-group> element in the authentication module's DeployableComponentConfig.xml.
lcid - The LCID of the section.
settings - an array of SettingVO objects (key-value pairs) that the authentication module requires to authenticate the request.

Exactly what settings you pass in the settings parameter depends entirely on the authentication module you use (see below). Here is an example:

// create a settings array
SettingVO\[\] settings = new SettingVO[3];
SettingVO svoUserId = new SettingVO();
svoUserId.setName("USERID");
svoUserId.setValue(userId);
settings[0] = svoUserId;
SettingVO svoAuthUrl = new SettingVO();
svoAuthUrl.setName("AUTHURL");
svoAuthUrl.setValue("http://www.webct.com");
settings[1] = svoAuthUrl;
SettingVO svoGlcId = new SettingVO();
svoGlcId.setName("GLCID");
svoGlcId.setValue(glcid);
settings[2] = svoGlcId;

// get a session via proxy login
String groupName = "/DeployableComponents" +
"/MyProxyLoginAuthModule";

SessionVO instructorSession = ctxt.login(groupName,lcid,settings);

The Authentication Module

Finally, you need the inbound authentication module to handle proxy login requests.

Authenticating Proxy Login Requests

How you authenticate proxy login requests is up to you. A relatively simple solution could be to create an authentication module that implements a shared secret type protocol.

For a shared secret type protocol, you would probably need to pass a user name, a message authentication code (MAC), and possibly some other parameters such as a timestamp. The authentication module would calculate its own MAC based on the setting values (not including the MAC passed in the settings) and compare its MAC to the one passed in the settings. If the MACs are the same, authentication succeeds and the login method returns a valid SessionVO object.

You can use the SessionVO returned by a proxy login to perform operations as if you were the instructor. Keep in mind that it's the implementation of the proxy login protocol in the authentication module that determines how secure this method is.

Getting the Settings

When handling standard HTTP requests, an inbound authentication module will usually look at the HttpServletRequest object returned by the getRequest() method to get parameters. It will also look at the Map containing the auth mod's settings returned by the getSettings() method.

Proxy login requests are somewhat different. For proxy login requests, you call the getSettings() method to get the settings that were specified in the ContextSDK.login(authModGroupName, lcid, settings) method.

NOTE: getRequest() returns null when handling proxy login requests.

But Wait... There's More!

If coding an auth mod for this seems like a bit much work, there's an easier way. The SSO v1 Module security authentication module provides a proxy login feature, which allows you to log in any user by passing the user's person ID and a MAC.

To use this feature, you must enable the auth mod and configure the Secret and GlcID settings in the server's System Integration API Standard Adapter settings. Once this is done, you can authenticate users via proxy as in this PHP example:

<?php
require_once('webct_mac.inc');

$context = new SOAPClient('wsdl/Context_login2.wsdl');

$lcid = 5116001;
$personId = 5917001;

$mac = calculateMac(array($personId), 'vienspluspres');

$settings = array();
$setting1->name = 'personId';
$setting1->value = $personId;
$settings\[\] = $setting1;

$setting2->name = 'MAC';
$setting2->value = $mac;
$settings\[\] = $setting2;

try
{         $session = $context->login('WsAuth', $lcid, $settings);         print '';
var_dump($session);
exit;
}
catch(SOAPFault $fault)
{         print '';
var_dump($fault);
}
?>

The first parameter to the login(authModName, lcid, settings) is "WsAuth" which tells WebCT to use the SSO v1 Module security auth to do a proxy login. The second parameter is the institution's LCID. The third parameter is the array of SettingVO objects. It must contain two SettingVOs. The first SettingVO must be named "personId" and contains the person ID of the user you want to log in. The second must be named "MAC" and contains a MAC of the person ID, calculated using the same shared secret that was configured in the server's System Integration API Standard Adapter settings.

Note that if you have multiple institutions on your WebCT server instance, this will only work for one of them. If you need to handle the others, you'll need to consider coding your own solution.

This article originally authored by Paul Monk on the WebCT DevNet