[To Be Designed]

WSE: The Kerberos Token Cache

At the risk of being accused of WSE-bashing, here's one more post. It's interesting to see what you find out when you profile a windows service over time and see the footprint gradually increase.

It turns out that the KerberosTokenManager maintains a token cache of 2048 tokens by default. I can only assume that the intent here is to prevent replay attacks. Interestingly, though, replay detection is off by default. Now, a Kerberos Token is not exactly a lightweight object. Ours weigh in at 2,275 bytes including child references. That's over 4 MB of token cache.

Now, to be fair, Kerberos Tokens do expire, and the cache does perform a flush of expired tokens whenever a new one is added. But the default lifetime of a Kerberos Ticket is 10 hours. Even a moderately busy service can easily reach the 2048 token maximum size before even a single expiration occurs if the default lifetime is used.

"OK," you say. "What's 4 MB these days anyway?" That's fair -- it's not that much. But the real kicker is what happens when the cache limit is reached and a new token is added. WSE performs a flush, and if the size post-flush is still at or above the max size, WSE just sends an entry to the application event log and adds the token to the cache anyway!

So, if your WSE-based service is handling a high volume of messages and you're using the default Kerberos implementation with default ticket lifetime, this can behave like a memory leak until the first token expirations. The cache size will increase unchecked until the first tokens begin to expire. Let's say you receive one message every two seconds - 30 messages / minute. That's 18,000 messages before the first message expires. At 2,275 bytes / token, the cache has a footprint of 40 MB.

This is all well and good, but (1) it isn't documented anywhere, and (2) a cache is being built that is never used.

posted by BailWatch Author @ 12:11 PM