Implementing authorization in a legacy system: challenges from the trenches

The scenario: delivering within limits

Challenges and solutions

1. Two sources of truth

2. Where the rule lives

• In the code: the rule is reviewed, versioned and tested along with the application, but any change requires a deploy.

• In a configuration file, like a JSON: it changes without touching the code, but it still needs a deploy and loses the compiler's checks.

• In the database, per route: it changes without a deploy and becomes a single source, but it starts requiring strong validation, because a wrong rule in the database is a security flaw in production.

3. The cost of each request and the cache

CACHE_TTL = 300  # seconds: only a safety net


def user_grants(user_id, cache, database):
    grants = cache.get(user_id)
    if grants is None:
        grants = database.grants_of(user_id)
        cache.set(user_id, grants, CACHE_TTL)
    return grants


def revoke(grant_id, cache, database):
    user_id = database.revoke(grant_id)
    # revoking clears the person's cache right away, without waiting for the TTL
    cache.delete(user_id)

• Cheap reads → the second lookup for the same person already comes from the cache.

• Immediate revocation → whoever loses access loses it right away, not five minutes from now.

• Expiry as a safety net → if an invalidation fails, the damage lasts at most as long as the cache expiry.

The risks of a generic engine

#Case 1: the missing field that authorizes

def naive_equal(required, granted):
    return required == granted


def equal(required, granted):
    return required is not None and required == granted


# no organization in the request, and none in the grant either
naive_equal(None, None)  # True: it authorized without knowing over what
equal(None, None)  # False

#Case 2: names that become the same

def normalize(name):
    return name.strip().lower().replace("-", "_").replace(" ", "_")


normalize("monthly-report") == normalize("monthly_report")  # True

import re

VALID_NAME = re.compile(r"[a-z][a-z0-9_]*")


def validate_name(name):
    # the name is checked when it's saved, not tidied up at decision time
    if not VALID_NAME.fullmatch(name):
        raise ValueError(f"name doesn't follow the pattern: {name!r}")
    return name

#Case 3: “any” instead of “all”

def any_of(required, granted):
    return any(target in granted for target in required)


def all_of(required, granted):
    return bool(required) and all(target in granted for target in required)


# the request touches two organizations; the grant only covers one
request = ["org-a", "org-b"]
granted = ["org-a"]

any_of(request, granted)  # True: the request would get through halfway
all_of(request, granted)  # False

#Case 4: the configuration error that only shows up on a request

#Case 5: the test that can't tell “denied” from “broke”

Influencing without deciding

• Read the constraint as a requirement: instead of fighting the limit, use it to design the solution. It was the constraint that led me to separate the data from the decision.

• Deliver what's yours, and deliver it well: a good solution within your scope is more convincing than a big proposal outside it.

• Leave the next step where the next person will find it: what was left for later — the cache and the startup validation — was recorded in the code itself, right next to where it would need to go.

• Show the cost before proposing the change: an architecture rarely changes because of an opinion, but it often changes because of a well-explained risk.

Roadmap and next steps

• Absence never authorizes, with isolation fields always required.

• Names checked when saved and compared exactly at decision time, with no wildcard aliases.

• Schema and rules validated at startup, before the first request.

• A coverage comparator for requests with several targets.

• A log of every decision, with the field that denied it, to investigate a denial without guessing.

• Property-based tests, which automatically generate thousands of cases to check rules that can never break, such as “a grant from one organization never reaches another”.

Conclusion