Can I delegate authentication by embedding an EKP login form directly in my portal?

Portals developed using the EKP Portal Toolkit typically use a process called delegated authentication that makes it possible for EKP to authenticate the user on behalf of the portal and thus avoid the problem of multiple logins.

In such cases, NetDimensions recommends including a Sign In link in the upper right corner of each portal page. Clicking the link initiates the delegated authentication process, which involves redirecting the user to EKP. If, as is typical, the user is not signed into EKP, he or she will be presented with the EKP login page, and will need to log into EKP before being redirected back to the portal with an appropriate authentication token. However, it is possible that the user might already be signed into EKP, in which case he or she will be immediately and transparently redirected back to the portal with the authentication token. This could happen for a number of reasons: the user's portal session might have timed out while his or her EKP session has not (which could happen if the session timeout for the portal is shorter than the session timeout for EKP); the user might previously have logged into EKP directly; or the user might already have signed into another portal running against the same EKP site.

The above is the approach followed in our code samples and by our portal demo sites.

Portal developers sometimes ask us if they can embed an EKP login form directly in their portal instead of using the sign-in link as described above. While this is possible, it creates a suboptimal user experience because it will in some cases force users to enter their user ID and password unnecessarily. This is because the only way for the portal to determine whether the user is already signed into EKP (which would allow them to bypass the login process as described above) is to redirect the user to EKP. However if the login form is embedded in the portal then this redirect does not occur until after the credentials have been entered. In other words, by the time we can determine whether the user's credentials are required, they will already have been entered, perhaps unnecessarily.

This situation might be acceptable if there is only a single portal, and if users of the portal site are unlikely to also access EKP directly. It becomes increasingly undesirable as the number of portals increases.

With the above caveats, here is an outline of how an embedded login form could be implemented if desired.

First, create a login form with the following fields:

• A hidden field named TX with value VERIFY;
• A text field named UID for the user ID;
• A password field named PWD for the user's password; and
• A hidden field named target, the value of which should be the absolute URL of a “post-login” callback page that is part of the portal, the purpose of which is described below.

Be sure that the form uses the POST method to ensure that the password is not included in the URL when the form is submitted. Note that there is no need to include the delegated authentication nonce or callback parameters in this form, since the handler will not use them.

Assuming that the base URL of the EKP site is https://www.example.com/ekp/ and the URL of the callback page is http://portal.example.com/post_login.php, this login form might look as shown below.

<form method="post" action="https://www.example.com/ekp/servlet/ekp">
 <input type="hidden" name="TX" value="VERIFY">
 <p><label>User ID: <input type="text" name="UID"></label></p>
 <p><label>Password: <input type="password" name="PWD"></label></p>
 <input type="hidden" name="target" value="http://portal.example.com/post_login.php">
 <p><input type="submit" value="Sign In"></p>
</form>

When the user submits the login form (and assuming he or she entered a valid user ID and password), he or she will be signed into EKP and then redirected to the “post-login” portal page. (If the user entered an incorrect user ID or password EKP will display the standard login page so that he or she can retry.) At this point, though, the portal has not validated that the login was successful. (The fact that the user has been redirected to the post-login page is not itself sufficient, since the portal can't reliably determine that the user didn't navigate to this page manually.)

At this point, the portal should initiate the delegated authentication process in the normal way, i.e. by generating a random nonce value, storing it in the session, and then redirecting the user to https://www.example.com/ekp/servlet/ekp/authenticate?nonce={nonce-value}&callback={callback-value}. Note that, since the user is already signed into EKP, he or she will not be shown the login page but will instead immediately be redirected to the callback URL with the authentication token, which the portal can then use to validate the login. In other words, this second step should be completely transparent to the user but allows the portal to verify that the login was successful.