Wednesday, May 26, 2010

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.

4 comments:

Romna said...

Good Day,

Could you please advise me about the following issue ?

i need to check if the user is authenticate only.

ex:
username : a123456
password: 1212121212

is declared user on EKP portal, now how i can check if the user authenticate and what is the required parameter(s) + URL ?

Robert Lowe said...

Romna, in most cases you should use delegated authentication as described here. Note that this provides a single login for both your portal and Talent Suite. Note also that following this approach you do not need to prompt your users for user IDs and passwords, since Talent Suite will prompt the user for these if necessary.

If you really just need to validate a user ID and password you can make a server-to-server call to any API function that requires user authentication and check whether the response code is 200 OK or 401 Unauthorized.

Romna said...

Thank you robert.

but i don't have a user to access the website.

could you please let me know how i can signup or if there's any guest account available ?

Thanks,

Robert Lowe said...

Romna,

If you purchased Talent Suite directly from NetDimensions then you should already have access to the wiki—please contact our support team if you don't know your username and password.

If you purchased Talent Suite from one of our resellers, please contact the reseller and ask them to help you arrange access.