Authenticate Case Study

The Authenticate web method is used by an integrating program to pass credentials to xWeb and gain access to xWeb. The web method returns a Token value which is then passed to subsequent web methods. xWeb web methods cannot be called unless passed with a valid Token.

Ideally, an integrating program should call this method as sparingly as possible because calling this web method adds overhead.

One Avectra client developed an authentication methodology that is explained in this case study. This model uses the Authenticate web method very infrequently, which results in a faster integration.

Keep in mind that these considerations become acute only when working with very high loads. If the pages on your site that use xWeb don't get a lot of traffic, then the topics on this page are less of a concern.

XWeb Configuration

First, the xWeb application is configured to use the Absolute Expiration policy with a long Timeout of 20 minutes. This means that when the Authenticate web method returns a Token, that Token value can be used over and over, by any threads, for 20 minutes (assuming no faults arise).

In older builds, for performance reasons, we recommended the Absolute setting for Expiration. As of 2008.01, the policies are equivalent from a performance standpoint.

Authenticate

Next, the integrating application set up a background process they called the "Token Pool" generator. This process ran in the background and maintained Tokens in an application pool that could be available to any user's web session. The Tokens have an expiration, and would automatically drop out of the pool when they expire. When a user went to a web page that needed to call xWeb, the page would look into the application pool, get a Token, and call the web method. If the method was successful and returned the same Token back, then great. If a fault occurred, the code for that page would alert the pool to remove that Token from the pool, then grab another Token from the pool, and go on its way.

When you are stringing together a series of web methods together, each one passing the token along, practice defensive coding to always ensure you get a Token back with a call. A call that returns a fault might not return a token in the SOAP header. In this case, the program will need to call Authenticate again (or, in this case study, go back to the "Token Pool") to get a new token and continue the operations.

The intelligence in this approach is that the code on the various web pages never actually calls the Authenticate web method, they just keep going to the Token Pool to get tokens. The Token pool, meanwhile, runs by itself and continuously makes sure it has a supply of fresh tokens.

This solution is also intelligent because the Tokens are shared across the entire application. Using the Absolute policy, it is perfectly fine for 2 or 10 or 100 threads to simultaneously use the same Token. This means that on an average day, you might only call Authenticate half a dozen times per hour because the Token can be used over and over (although it wouldn't hurt to call it every minute -- the idea is you don't want to be calling this method every second).

What, technically, is this "Token Pool"? It could take the form of an "application" variable in the form of an array or some other structure, or a local database table, an Xml file stored on the server, or any other way you can think of that suits your application.

Implementing a Token Pool

Here is a simple approach to developing this, using a .NET mentality that you could adapt to other programming languages:

Simple Approach

  1. You need to call a web method.
  2. Look for an "application" object (an array?) that has two dimensions. Dimension 1 is Token, Dimension 2 is ExpirationDate.
  3. Get the first Token, check the ExpirationDate. If the ExpirationDate is still valid, then use that Token. If the Token works, great. If the Token does not work (which shouldn't happen), then remove it from the "application" object so no other threads use it. If the date is expired, remove it from the "application" object so no other threads use it. Go to the next array element and check for that Token.
  4. If the array element is out of Tokens, then call Authenticate, get a Token, but it into the "application" object along with an ExpirationDate that is less than the Timeout setting, and use it.

More Robust Approach

Essentially, the same as the "Simple Approach", but as described higher above, have something running in the background, but within the same application, continuously monitor the "token pool" to make sure there is a fresh over supply of tokens. Don't just have one Token, as if that Token produces a fault, you want to have plenty of others available for other applications. So, in your code, you might want to have a threshold of available Tokens, say 100 (make it a configurable option in case you need to raise or lower; you'll want to keep it as low as safely possible). Keep calling Authenticate as often as you need to ensure you always have 100 active Tokens "in your pocket" at all times and ready to hand out.

The Token Pool should try to mix up the tokens it "gives" to callers, in case of faults. If you just gave out Token abc-123 to 20 callers, and caller 2 faults that token, then the other 19 will find that their token is no longer good. For this reason, you should "hand out" tokens in a rolling manner to minimize "over relying" on any one Token that could be used by many simultaneous threads.

Alternative to Token Pool

If developing an application wide "token pool" is not possible, then at least have each web user keep using the same token over and over. Do not generate a new token for each burst of activity. Generate a token once, keep it in session, and keep using that token. If the site has the Sliding Expiration policy, then every time you call a method, you get back a fresh token with a new timeout. Keep this in session and keep passing it, getting a new value, passing it again, etc. Have code to catch a timeout exception, if the Token gets old, and call Authenticate again only when you have to.

If you have Absolute tokens, then keep using it for as long as you can, until you catch a timeout exception, and then you can call Authenticate again. You might want to put the Token into session, and also store a Token timeout. Assuming the Timeout is 20 minutes, then you might want to store in session what time it will be 19 minutes after you authenticate. Then, every time you use the Token, make sure the time is before that future date; if after, then call Authenticate again and get a new Token.

Best Practice and Worst Practice

In descending order, best practices are:

  1. The best: Set up a shared "Token Pool" across an application.
  2. Each user session authenticates once and echoes that Token in each subsequent call.
  3. Each user authenticates at the beginning of each "burst" of web methods, and echoes that Token in each subsequent web method call in that "burst"
  4. The worst: programming in such a way that EVERY call to XWeb runs its own authenticate.

Consider what these four profiles would look like on a site using the Absolute expiration policy that has 10,000 visitors in a day, with each visitor clicking around enough to generate 10 separate xWeb calls each.

Profile Authenticate
Count 		Comments
Token Pool 1,000 Just a guess. Let's say we generate a new Token per minute, and slow it down at night. That's about 1,000 per day, with each Token getting "shared" by ten users.
One Token per User Session 11,000 One Token for each user, but lets say that 10% of users browse for longer than the Timeout, so they'll need a new token.
One Token per "burst" 50,000 Let's say each user produces five separate "bursts" each on the site. That's 5 X 10,000.
One Token per call 100,000 This is the absolute worst practice. 10,000 users, 10 calls each, is 100,000 Authenticate calls

As you can see, the better you can structure your application, the fewer web method calls you'll need to make.

Keep in mind that calling Authenticate once a minute is harmless; you just don't want to call it 100 times a minute. If your site rarely tops 1,000 visitors per day, then just go with the "One Token per User Session" profile and you should be fine as you will be calling Authenticate maybe 100 times per hour over a 10-hour business day.

Summary

It is easier to just call Authenticate every time, but don't do it. Spend a little more time up front considering these case studies and do it right. Manage your tokens intelligently. You might not think it matters much initially, and you might find that running a single Authenticate only takes a few milliseconds, but we have found that on very high load web sites, you'll want to do everything you can to call xWeb only when needed. Eliminating wasteful and redundant Authenticate web method calls is a good way to start.