Question

Precondition: There’s a web application that leverages ASP.NET security model. There’s also an Active Directory (AD) integration component. It provides AD users and roles as if those are application’s own users and roles. The relations like “is in role” between AD user and AD role are stored in AD domain, of course, but are cached by the web application.

Problem: Let’s say AD user1 is a member of AD role1. When web application starts, it caches this relation. Now if the AD administrator removes user1 from role1 using AD console, the application doesn’t know about this change – the cache entry is kept. This becomes a security hole because the role1 might have permissions the user1 should no longer have.

There are two сcontrary opinions how to solve this:

1. “Listen” to AD changes and trigger cache entry removal once the operation is detected on AD server – because we are responsible for correct AD component functioning
2. Leave the cache untouched – because we didn’t put the entry there and should not remove it either

What’s the right way to go in this case? And why?

Thank you!

Answer 1

I think it should be the responsibility of the implementer of the component that uses a caching mechanism.

In many cases, some latency in propagation of changed permissions might be acceptable.
So a cache entry that uses a reasonably small absolute timeout might be acceptable.

If such latency is not acceptable, then caching is probably not appropriate anyway.

The implementor of the caching mechanism ought to document this. If I was doing it, I’d have a documented configurable absolute timeout, so that administrators could judge how much latency is acceptable, and could disable the cache altogether. I might also provide an API or UI that enables an administrator to manually clear the cache.