Case study · Insurance, ~320,000 users

A global authorization platform on OPA

One policy language for the whole organisation, with every decision logged. The hard part was never the policy engine; it was getting several delivery teams to agree on what a decision means.

Discuss a similar project All selected work

The situation

Authorization was decided per application

Around 320,000 users, and no shared answer to who is allowed to do what.

Each application carried its own authorization logic, written by the team that built it. That works until an auditor asks why a specific person could see a specific record, and the answer lives in four codebases and a database table nobody has opened this year.

The organisation wanted a shared authorization service: one policy language, one decision log, and enforcement points that applications could adopt without rewriting themselves. The programme spanned several delivery teams, an external partner and a compliance function with a genuine interest in the answer.

What I built

A policy platform, and the evidence to trust it

Architecture, implementation and the delivery pipeline that keeps policy changes reviewable.

  • The policy architecture: policy decision and enforcement points, administration and information points, modelled on NIST 1800-3B rather than invented for the occasion.
  • Shared cross-domain policies, and the comparison between running them on open-source OPA and OPA Enterprise that made the decision answerable on paper.
  • A Kafka-based decision-log plugin in Go, with Parquet in S3 through Kafka Connect, ClickHouse for analysis, and alerting in Dynatrace and Prometheus.
  • The CI/CD move from GitHub Actions to Dagger, including secure push, blackbox policy tests with Raygun, Rego unit tests and debugging inside VS Code.
  • An agentic prototype that exposed the Rego language server over the Model Context Protocol, so policy and test drafts could be generated against the real language semantics.
  • Tech talks and workshops on decision logging, plus the standing architecture syncs that kept several delivery teams aligned.

What changed

A decision you can point at

  • One authorization service with a shared policy language, instead of per-application decisions.
  • Every policy decision auditable through the decision log, which turned “why was this allowed?” into a query.
  • Test coverage above 80% in a codebase where policy had previously been reviewed by reading it.
  • Teams outside the programme could write and test their own policies without shipping a service.

From the programme

Christof was the Product Owner on the authorization work for almost a year.

He is well rounded from requirement management to architectural concepts, hands-on developing, and testing.

Christof V. Product Owner, reinsurance company LinkedIn recommendation

Stack

What it runs on

Start the conversation

Building authorization across teams?

A short note with the environment, the constraint and the timing is enough for me to say whether this is a fit.

Discuss your project All selected work