Tips on integrating Articulate-created content with an LMS

On Articulate's Word of Mouth Blog, Gabe Anderson has posted a useful checklist of things to look for when integrating Presenter- or QuizMaker-created content with an LMS.

Search EKP's catalogs from your browser's search box

EKP 5.0 makes it possible to search EKP's course catalogs directly from the search box of Internet Explorer 7 or Firefox 2.

When a user visits EKP using Internet Explorer 7, the drop-down arrow of the search box "lights up" to indicate that EKP has been added to the drop-down menu.

To add the EKP search provider, select Add Search Providers from the drop-down menu, then select Enterprise Knowledge Platform by NetDimensions.

Internet Explorer will prompt you to confirm that you want to add the search provider.

After clicking Add Provider, select Enterprise Knowledge Platform by NetDimensions from the drop-down menu.

With the EKP search provider selected, initiating a search from Internet Explorer's search box opens EKP's catalog search results page directly.

Similarly, when a user visits EKP using Firefox 2, the drop-down arrow of the search box "lights up" to indicate that EKP has been added to the drop-down menu.

To add the EKP search provider, select Add "Enterprise Knowledge Platform by NetDimensions" from the drop-down menu.

With the EKP search provider selected, initiating a search from Firefox's search box opens EKP's catalog search results page directly.

How can I publish an Articulate Quizmaker quiz as an AICC course package that I can import into EKP?

Articulate Quizmaker is capable of publishing quizzes as both SCORM and AICC content. EKP can import and deliver both formats. One advantage of publishing as AICC content is that learners do not have to have Java installed in order to take the quizzes. However, there are a few points to bear in mind when publishing Quizmaker quizzes as AICC content. By following the steps below, you can publish a quiz as an AICC course package and import the package into EKP.

1. Click the Publish button in the Quizmaker toolbar.
2. In the Publish window, choose LMS from the left menu.
3. In the LMS field under Output Options, select AICC.
4. Click Reporting and Tracking...
5. Under LMS Course Information in the LMS Metadata window, complete the Description and Creator fields. Note that if you leave these fields blank, Quizmaker will omit these fields from the published AICC files, resulting in files that are invalid according to the AICC specification. Therefore, in order to produce a valid AICC course package, you must complete these fields before publishing the quiz.
6. The default value of the Filename(URL) field is http://www.servername.com/quiz/index_lms.html. While it's possible to replace this with the full URL at which the quiz will be published, it's easier to simply remove the initial portion so that the value becomes just index_lms.html. (Note that the value should not contain any slash characters.) If you then import the quiz into EKP as an AICC course package as described below, EKP can automatically deduce the full URL needed to launch the quiz.
7. Click the OK button to dismiss the LMS Metadata window.
8. In the Publish window, under Output Options, ensure that the check box labeled Zip files is checked.
9. Click Publish.

The resulting zip file can be imported into EKP using the Import Content Package function (Manage > Catalog Manager > Import Content Package)—simply follow the on-screen instructions.

In summary, the important points are as listed below.

• Be sure to complete the Description and Creator fields in the LMS Course Information section of the LMS Metadata window.
• Enter index_lms.html in the Filename(URL) field.
• Under Output Options in the Publish window, ensure that the check box labeled Zip files is checked.
• Import the published zip file into EKP using the Import Content Package function.

EKP 4.7 Courselets

We've just published the second of a two-part series of "courselets" covering the new features in EKP 4.7. This part specifically covers features related to exam authoring, management and delivery. (Features not specifically related to exam management were covered in part one.)

Can I launch courses directly from a portal so that learners don't have to log into EKP, but still have EKP track the learners' progress?

In order to link to a course so that the course launches immediately, and is tracked by EKP, you can link to the launchByCourseId transaction, e.g.:

/ekp/servlet/ekp/launchByCourseId?courseId=My_Course

(Note that this requires that the learner already be enrolled in My_Course, so you might want to pre-enroll learners using a Group Enroll or Auto-Enroll.)

If you link directly to the URL above, and the learner does not yet have a session with EKP, she will be prompted to log in as normal. In order to achieve “transparent login”, you can use one of the two mechanisms described below.

1. Implement the "external authentication service" mechanism. To implement this, the portal would need to be modified to generate “authentication tokens” (cryptographic hashes) when requested by EKP. Then, EKP's configuration is modified so that, when it needs to authenticate a user, it redirects to the portal to request an authentication token instead of showing the standard login page.
   
   Note that this mechanism has the significant advantage that it is not required that users' passwords be synchronized in the two systems. In fact, when using this mechanism, the passwords stored in EKP's database are never used.
2. Use the standard verify transaction. This is the transaction that is used to validate a user ID and password submitted using the normal login page. It is possible to add a target parameter to specify the page to which the user should be redirected after a successful login (instead of the normal home page). In particular, if you want to start a course after login, you can specify the launchByCourseId transaction (with appropriate courseId parameter value) as the value of the target parameter. E.g.:

   /ekp/servlet/ekp?TX=VERIFY&UID=joestudent&PWD=password&target=%2Fekp%2Fservlet%2Fekp%2FlaunchByCourseId%3FcourseId%3DMy_Course

   Note that the value of the target parameter has been percent-encoded.
   
   The above example includes the parameters in the query string—however, for security reasons you should avoid including the user ID and password in the URL—therefore, the portal should be coded to use the POST method rather than GET to invoke the verify transaction.

Note that, unlike method 1, method 2 requires passwords to be synchronized between the two systems, which could be difficult to achieve if passwords are changed regularly (a good security practice). (This problem can be avoided by configuring both systems to use the same directory server, i.e. Active Directory or LDAP.) In addition, method 2 requires embedding the user's password in an HTML page (or HTTP redirect header), which might be cached. For these reasons, we recommend using method 1 if possible.

Can I use an external authentication service so that users don't need to log into EKP directly?

(Note: this post contains technical details that will likely be of most interest to developers.)

In a typical organization, EKP will be one of many applications that employees or other stakeholders use on a regular basis. In this situation, it's typically desirable to provide some kind of single (or reduced) sign on, so that users don't have to perform separate logins to different applications.

EKP provides a number of mechanisms to help solve this problem. Some of those most commonly-used are listed below.

• Support for LDAP and Active Directory services: Use of an LDAP or Active Directory service avoids the needs to store and update users' passwords in EKP's database, because users' credentials are checked against the centralized directory service when they log in. This works even if the user is accessing EKP over the internet. However, it does not actually eliminate the need for the user to perform a login to access EKP. (For details of LDAP- and Active Directory-based authentication, see the LDAP Authentication Integration Configuration Guide and the Active Directory Authentication Integration Configuration Guide respectively.)
• Support for Integrated Windows Authentication: Use of Integrated Windows Authentication avoids not only the need to store and update users' passwords in EKP's database, but also the need for users to explicitly log into EKP, because their identity is automatically propagated to EKP based on their Windows login. However, Integrated Windows Authentication typically only works within a Windows-based intranet; it typically will not work for access over the internet. (For details on using Integrated Windows Authentication with EKP, see the Single Sign-On Integration with Windows document.)

However, it's often desirable to provide an integrated authentication mechanism that will work over the internet, even if the authentication service is not physically co-located with EKP. This post describes such a mechanism.

For the sake of example, let's suppose that you are running a company portal alongside EKP, and that you want your portal users to be able to access EKP. However, you do not want users to have to log into EKP separately; rather, you want all authentication to occur via the portal, with users' identities being propagated to EKP once they have authenticated through the portal.

In order to enable the integrated authentication mechanism, it's necessary to define a couple of properties in the ekp.properties configuration file (under the WEB-INF/conf/ directory), as shown below.

authentication.key=mysecretkey
authentication.service.url=http://portal.abc.com/login.asp

The significance of these properties and their values is explained below. In addition, another optional property may be specified, as shown below.

authentication.digestAlgorithm=SHA

The value of this property specifies the cryptographic hash function that will be used as part of the authentication process, as explained below. Permitted values are MD5 and SHA. If this property is not specified, a default value of MD5 is assumed.

Normally, when an unauthenticated user tries to access a page in EKP that requires authentication, she will be redirected to EKP's standard login page. With the integrated authentication mechanism enabled, she will instead be redirected to the URL specified by the value of the authentication.service.url property. (Note that it does not matter how the user came to access the EKP page. She might have accessed the page by following a link from the portal, but that's not necessary for the mechanism to work.)

EKP will also append a query string parameter named salt to the URL that is the target of the redirect. The value of this parameter is a random sequence of bytes, converted to characters using Base64 encoding. The purpose of the salt value is to prevent replay attacks—which is to say that if an attacker was able to intercept the URL generated by the portal as described below, they would not be able to reuse it authenticate against EKP after the salt value expired.

An example of a possible redirect target URL is shown below.

http://portal.abc.com/login.asp?salt=OqQ1uao%3D

(N.B. In this example, the raw Base64-encoded salt value is the character string OqQ1uao=. However, the equals character “=” has special meaning when used in URLs, so the value has been URL-encoded as OqQ1uao%3D.)

On receiving the request from the redirected client, the portal needs to perform the following steps.

• Recover the original bytes of the salt by Base64-decoding the URL parameter value.
• Authenticate the user if she does not already have a session with the portal.
• Using the function configured as described previously, calculate a cryptographic hash of the user ID, secret key (this is the value of the authentication.key property described above) and salt value.
• Convert the bytes of the cryptographic hash to a character string using Base64.
• Redirect the client back to EKP's authenticationTokenVerifier transaction, passing both the user ID and the Base64-encoded cryptographic hash as query string parameters.

For example, assuming that the user is authenticated by the portal as joestudent, and the secret key is mysecretkey, then the MD5 cryptographic hash (after Base64 encoding) would be vf1nZ7R2YSoso+g+BLLVog==, and the EKP URL to which the portal would redirect the client would look as shown below.

/ekp/servlet/ekp/authenticationTokenVerifier?userId=joestudent&digest=vf1nZ7R2YSoso%2Bg%2BBLLVog%3D%3D

(Note that the value of the digest parameter is the URL-encoded cryptographic hash.)

On receiving the request from the redirected client, EKP will perform its own computation of the cryptographic hash and compare it with the value passed by the portal. If the values match, this is accepted as proof that the redirect was actually generated by the portal and was not “spoofed”. EKP then considers the client to be authenticated and establishes a session with the client.

The following sample code provides an outline of how the mechanism described above might be implemented as a Java servlet.

String saltStr = req.getParameter("salt");
byte[] salt
  = new sun.misc.BASE64Decoder()
      .decodeBuffer(saltStr);
  
String key = "mysecretkey";
String userId = "joestudent";
  
// Calculate a digest
java.security.MessageDigest md
  = java.security.MessageDigest.getInstance("MD5");
  
// Convert user ID and key to bytes--need to
// specify a character encoding here in case the
// default encodings are different on the two
// systems.
md.update(userId.getBytes("UTF-8"));
md.update(key.getBytes("UTF-8"));
md.update(salt);
byte[] digest = md.digest();
  
// Use Base64 encoding to turn the digest into a
// string, so we can pass it in the URL.
String digestStr
  = new sun.misc.BASE64Encoder().encode(digest);
  
// Encode the digest again using URL encoding to
// escape any special characters.
String url
  = "http://ekp.abc.com/"
  + "ekp/servlet/ekp/authenticationTokenVerifier"
  + "?userId="
  + java.net.URLEncoder.encode(userId, "UTF-8")
  + "&digest="
  + java.net.URLEncoder.encode(digestStr, "UTF-8");
  
response.sendRedirect(url);

The mechanism described in this post works in EKP 4.6 Gold build 116 or higher, and in EKP 4.7 Gold build 52 or higher.

Can I remove the calendar view that displays on the right side of the Enrolled Learning Modules tab?

By default, EKP displays a calendar view on the right side of the Enrolled Learning Modules tab.

This calendar view can be hidden for a specific skin by adding a Cascading Style Sheet (CSS) rule to the main style sheet for the skin. The rule is as shown below.

.enrolled-learning-modules-calendar {
   display: none;
}

For an explanation of how to locate the file to which this rule should be added, see this previous post.

Please note that this requires one of the following builds: EKP 4.5 build 190 or higher; EKP 4.6 build 61 or higher; or any EKP 4.7 build. The CSS rule will have no effect on earlier builds.