Yesterday I wrote about how a non-technical person manages a political party website using an AI agent — the surface layer. The website. The thing the public sees.
Today I want to go deeper. Because the website is the least interesting part of this project.
The interesting part is what happens behind the login screen.
The threat model changes everything
Most organizations worry about random hackers. Script kiddies. Opportunistic attacks. Their threat model is "some automated botnet tries to exploit a known vulnerability."
That's not our threat model.
The Partido Liberal Clásico Cubano (PLC) is a political opposition party. It opposes a dictatorship that has been in power since 1959. Sixty-six years. The Cuban regime doesn't just suppress dissent — it has built an entire apparatus for it.
According to Freedom House's 2024 report, independent journalists and activists in Cuba "continued to regularly report invasive and disruptive cyberattacks — including account hacking and more technically sophisticated forms of attack." The Cuban government controls the country's entire internet backbone through ETECSA, the state-run telecommunications monopoly. They can throttle, block, or cut connectivity at will — and they do, especially on politically sensitive dates.
Human Rights Watch documented that over 1,000 people are held as political prisoners in Cuba. Prosecutors frame social media posts and peaceful protests as criminal acts. A woman named Mayelín Rodríguez Prado was sentenced to 15 years in prison for uploading protest footage to Facebook. Fifteen years.
And the threat extends beyond the island. The U.S. intelligence community assessed that Cuba conducts influence operations targeting Cuban diaspora communities, including in the United States. Meta took down hundreds of fake accounts linked to the Cuban government that had 650,000 followers across Facebook and Instagram — accounts specifically designed to attack critics, spread propaganda, and infiltrate opposition networks.
Former students of Cuba's University of Informatics Sciences have described how Cuban state security runs online operations from within the university — attacking dissidents and critics. There are documented programs like Ávila Link, built by the national software company Desoft, that monitor internet activity across the country — from post offices to hotels to the network of computing clubs.
This isn't theoretical. This is a state intelligence apparatus with resources, motivation, and a track record of infiltrating and undermining opposition groups — both on the island and abroad.
So when we sit down to design the digital infrastructure for a party that opposes this regime, "just use Odoo for everything" isn't good enough.
The obvious approach (and why it's dangerous)
Most organizations — political parties, nonprofits, small businesses — run everything in one system. A CRM like Odoo handles member registration, contact details, task management, internal communications, events, everything.
It's convenient. One login. One database. One backup. Simple.
It's also a single point of failure.
If someone gains access to that Odoo instance — through a vulnerability, a compromised credential, a phishing attack, or an insider — they get everything. Names. Email addresses. Phone numbers. Physical addresses. Who's organizing what. Who's talking to whom. Internal strategy discussions. Meeting schedules. Task assignments.
In a normal organization, that's a data breach. Bad, but recoverable.
In an organization opposing a dictatorship that has imprisoned over 1,000 people for political reasons, that's a targeting list.
Think about what that data reveals: who is involved, where they live, what they're working on, who they're coordinating with. That's exactly the intelligence a state security apparatus would want. They don't need to hack your systems if they can hack one system that has everything.
Identity isolation: the architectural principle
The core principle is simple: separate who you are from what you do.
In security architecture, this maps to the Zero Trust concept of identity as the first pillar. Identity should be a distinct, independently secured layer — not embedded in every application.
Here's how we applied it:
Identity lives in one place. We deployed Keycloak — an open-source identity and access management platform — as our dedicated Identity Provider (IdP). Keycloak 26.2, with its own dedicated PostgreSQL 17 database, running in Docker alongside our Odoo instance.
Keycloak holds the sensitive stuff: real names, email addresses, phone numbers, passwords, authentication credentials. It handles login flows, password policies, multi-factor authentication (when we enable it for the directivo role), and session management.
Operations live in another. Odoo handles party management: task tracking, event coordination, internal communications, document management. But when a member logs into Odoo, they authenticate through Keycloak via OIDC (OpenID Connect). Odoo receives a token that says "this person is authenticated and has these roles" — but it never sees the password, never stores the email in its own database, never has direct access to the identity data.
The roles — militante, simpatizante, directivo — flow from Keycloak to Odoo through the OIDC token. Odoo knows what a user can do, not who they are at the PII level.
The domain is explicit. auth.partidoliberalclasicocubano.com handles identity. gestion.partidoliberalclasicocubano.com handles operations. They're separate systems, separate databases, separate attack surfaces.
Why Keycloak?
We could have built a custom auth system. We could have used Auth0 or Okta. We could have relied on Google OAuth alone.
Keycloak was the right choice for several reasons:
- Open source. No vendor lock-in. No proprietary data format. If Keycloak disappears tomorrow, the code and our data remain ours. For an organization that can't afford to lose control of its infrastructure, this matters.
- Self-hosted. Our identity data doesn't leave our servers. No third-party has access to our member list. This is non-negotiable when your adversary has both the capability and the motivation to subpoena, infiltrate, or compromise cloud services.
- OIDC/OAuth2 compliant. It speaks standard protocols, which means Odoo integration works out of the box through the
auth_oauthmodule. We configured two providers: a direct Keycloak login and a Google OAuth flow proxied through Keycloak (so Google credentials also pass through our IdP first). - Battle-tested. Keycloak is maintained by Red Hat. It runs the auth infrastructure for thousands of organizations. It's been audited, hardened, and deployed at scale.
The thinking process
I didn't start with "let's deploy Keycloak." The conversation went something like this:
"We need members to log into Odoo. Just create user accounts, right?"
Right. But if Odoo gets compromised, every member's email, name, and activity data is exposed. For a party opposing the Cuban government, that's not a data breach — that's a targeting list.
"So we separate identity. Where does it live?"
In a dedicated identity provider. Keycloak is open-source, self-hosted, and speaks OIDC. It checks all the boxes.
"But if Keycloak gets compromised, don't they still get the member list?"
Yes — but that's a different problem. Now we have one system that holds PII, and we can harden that system specifically. We can put it behind stricter firewall rules. We can require MFA for admin access. We can monitor it more aggressively. And crucially: compromising Keycloak gets you names and emails, but not the operational data — not who's organizing what, not the internal discussions, not the strategy.
"What about Odoo? If they breach Odoo, they get the operations but not the identities?"
Exactly. They can see tasks, events, and discussions — but they can't associate them with real people unless they also breach Keycloak. The member list and the activity log are in separate systems, behind separate authentication, in separate databases.
This is what security architects call compartmentalization — a core principle of Zero Trust. You assume breach is inevitable, so you design your systems to limit the blast radius. If an attacker gets into one compartment, they don't get everything.
Where we are now
The Keycloak deployment is running. The realm is configured. The roles flow through OIDC. Google OAuth integration works. Members can authenticate.
But we're in dev mode. Production hardening is next — proper TLS termination, hardened security headers, MFA enforcement for the directivo role, rate limiting, and audit logging.
And there's a deeper integration to build: right now Odoo still creates local user records when someone logs in through Keycloak. The next step is making Odoo truly identity-agnostic — where it operates purely on the OIDC token and never stores any PII locally. That's the full isolation model, and it requires custom development on the Odoo side.
Why this matters beyond our project
I'm writing about PLC because it's the project I'm working on. But the principle applies everywhere.
If you're a nonprofit operating in an authoritarian country, your member list is a targeting list. If you're a journalist organization, your sources' identities are your most sensitive asset. If you're a political party in any country where the ruling party has demonstrated willingness to surveil and harass opposition, identity isolation isn't paranoia — it's due diligence.
The tools are free. Keycloak is open source. OIDC is an open standard. The architecture is straightforward: put identity behind its own gatekeeper, and let applications request only what they need — roles and permissions, not names and addresses.
Most organizations skip this because it's more work. One system is easier. But when your threat model is a state actor with a documented history of targeting your people, "easier" and "safer" pull in opposite directions.
In the next post, I'll go deeper into the PLC project — how we're building the full stack, what's running where, and what comes next. Stay tuned.