Thursday, June 28, 2007

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 configuration file (under the WEB-INF/conf/ directory), as shown below.


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


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.

(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.


(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()
String key = "mysecretkey";
String userId = "joestudent";
// Calculate a digest md
// 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.
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
  = ""
  + "ekp/servlet/ekp/authenticationTokenVerifier"
  + "?userId="
  +, "UTF-8")
  + "&digest="
  +, "UTF-8");

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.

Enrolled Learning Modules tab with calendar view

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.

Monday, June 25, 2007

I have entered a Request For Enhancement in TestTrack Pro, why isn't it available on the enhancememts voting site?

All Requests For Enhancement entered into TestTrack Pro will be considered for inclusion on the enhancements voting site. Requests will generally be accepted for inclusion if they meet the following two criteria.

  • The Summary and Description fields should not contain any confidential information—that is, any information that you would not want other NetDimensions customers or partners to see. Please be aware that we need to be cautious here, so where there is any doubt we will tend to assume that information about specific users, organizations, courses etc. may be confidential unless this is clearly not the case. Note that such information can be added as comments to the TestTrack Pro issue, since these will not appear on the voting site. Also bear in mind that use of your organization-specific terminology or other organization-specific information might reduce the clarity of the suggested enhancement for other voters—see below.
  • Many screens in the voting site display only the issue summary, not the full description. Therefore, it needs to be reasonably clear from the summary alone what the proposed enhancement is, including both the specific change and the context. For example, if you wanted to suggest adding the ability to clone user roles, neither "Clone function" nor "Enhancement for User Roles" would be a sufficiently descriptive summary field. (The former does not indicate what the clone function would actually clone, while the latter only indicates that the enhancement would affect user roles, without specifying what it would actually do.) On the other hand, "Add a function for administrators to clone user roles" would be a perfectly acceptable summary.

Of course you are still welcome to submit enhancement requests that do not meet these criteria—it's just that they probably won't appear on the voting site.

Note that we will generally not edit issues that don't meet these criteria—we don't want to put words into your mouth! However, if you have entered a TestTrack Pro issue that currently does not appear on the voting site, you are welcome to edit the issue yourself and we will happily reconsider it.

Finally, please note that issues that are accepted for the voting site won't necessarily appear right away. The voting site is a work in progress and we're still refining the process by which the site will be synchronized with TestTrack Pro. In the long run our aim is that it should take no more than a week or so for new enhancement requests to appear on the voting site, but in the initial stages it might be several weeks before your enhancement requests appear. We appreciate your patience!