Why verified participation changes the build for online voting
A public body running online voting or signature collection must be able to show that each participant is an eligible resident and that each person has counted once. That obligation sits in the design of the verification layer, not in the voting screens. The practical answer is to treat identity as a separate layer from the participation platform. On a self-hosted Decidim site, that layer is built from authorization handlers in the Decidim authorization framework, which can check a census file uploaded by the body, a government eID, or a single sign-on source connected through OmniAuth. Many teams place Keycloak between Decidim and the identity source so that one broker handles protocols such as OpenID Connect and SAML 2.0, and the platform only receives a verified attribute set. The platform choice is Decidim. The identity source is a decision the body makes with its own registries and legal advisers, and it should be settled before the build starts.
Verification design decides legal exposure because the questions a regulator, auditor or court will ask are about the records: which source established eligibility, what was stored about each participant, who could read it, and how long it was kept. A voting screen can be accessible and well tested and still create liability if the census import keeps full personal records longer than the process needs, or if a single sign-on link lets one person authenticate under several accounts. Confirm with your legal team which lawful basis applies to each data flow, which attributes the process actually needs, and whether the identity source sits inside the jurisdiction you are bound by. Ask the implementation partner to document each authorization handler, the data it receives, the retention setting applied to it, and the test cases showing that a second registration with the same identifier is refused. Those documents become the evidence base for both the public body and any later assessment.
Which requirements shape verified voting and signing
This table compares the requirements that shape identity checks for online voting and signing, the source of each one, and what it changes in the build. Read each row as a question to settle with your legal, accessibility and security owners before choosing an authorization method. The main takeaway is that eligibility rules and accessibility duties are set outside the software, so they should be written down before any handler is configured.
| Requirement | Source | What it means for the build |
|---|---|---|
| Accessible verification and sign-in forms | ADA Title II rule for state and local government web content, requiring WCAG 2.1 Level AA; compliance dates set by the interim final rule published April 20, 2026 | Test every authorization step, including code entry, document upload and error messages, with assistive technology before launch. Confirm which compliance date applies to your entity. |
| Eligibility to vote or sign | Your organization's own rules, such as residency, age or district membership, as defined in law or bylaws | Decide which attributes prove eligibility, then map each to a Decidim authorization handler or an identity provider claim. Confirm the rule wording with counsel before coding. |
| Data minimization for verification data | Data protection principles such as those in GDPR-style regimes, to be confirmed with counsel for your jurisdiction | Store only the attributes needed to decide eligibility, and avoid keeping full identity documents once the check passes. Record which fields are kept and why. |
| One person, one vote or signature | Your process rules and, where applicable, election or petition law | Configure a unique identifier per participant and test duplicate sign-in attempts. Confirm with counsel how an identifier is derived and whether it is pseudonymous. |
| Retention of verification records | Your retention schedule and records law, confirmed with counsel and records officers | Set deletion or anonymization jobs for census files and verification logs separately from votes and signatures. Document the schedule before go-live. |
| Auditability of the check | Internal audit and any external assessor's evidence requests | Keep logs that show when a check ran and its outcome without recording the underlying identity data. Confirm with the assessor what evidence they expect. |
| Identity provider availability and access | Your identity architecture, including any government eID or SSO service | Decide how a Keycloak or other OmniAuth provider is hosted and whose administrators can change identity settings. Confirm the provider's support terms and upgrade policy. |
Which identity and voting options fit eligible-voter checks
Eligible-voter checks usually combine three layers: what Decidim does natively, what a social login proves, and what a government identity source can confirm. Each option below answers a different question, so the choice depends on whether you must prove residency, prove a legal identity, or only prove a single account.
Decidim authorization handlers
Decidim's authorization handlers are the built-in way to gate proposals, votes and signatures behind a verification step that you configure per organization. They suit cases where the check is a defined rule, such as a postal code or an identifier you already hold. Confirm which handlers ship in the version you deploy, and test each one against your own eligibility rules before launch, since a handler only enforces what it was written to check.
Census upload for known electorates
A census upload lets you load a list of eligible participants so that only matching records can take part. It fits closed processes such as a staff assembly or a defined neighborhood vote, where the electoral roll is authoritative and already exists. Plan who produces the file, how it is validated, how duplicates are handled, and when the census is locked. Treat the file as personal data with its own retention rule, because it holds the eligibility basis for every participant.
OmniAuth social providers
Decidim supports Facebook, Twitter, Google and Decidim-to-Decidim OAuth 2.0 login out of the box, and any other OmniAuth strategy can be added as a custom provider. These logins prove that someone controls an account, not that they live in the jurisdiction. Do not treat a social login as residency or eligibility evidence. Use it for sign-in convenience, and pair it with an authorization step that checks eligibility.
Keycloak as identity broker
Keycloak is an open source identity server under Apache 2.0 that supports OpenID Connect, OAuth 2.0 and SAML 2.0. It brokers logins to upstream identity providers and can federate user directories, so a single gateway can sit between Decidim and your government or campus identity sources. This is the component to evaluate when a national eID or institutional SSO must be the verification source. Confirm each eID provider integration in your own environment, including the certificates, protocol profile and attribute mapping it requires.
One person, one vote controls
Gating access does not by itself stop one person from voting twice with two accounts. Decide how each verified identity maps to a single participant record, whether a duplicate identifier is rejected, and how re-registration is handled. Test these rules with the identity source you choose, because the strength of the control depends on whether the identity source issues a stable unique identifier. Confirm that behavior with your identity provider vendor before you commit.
How the deployment pattern changes by identity source
A census upload is the simplest pattern. The organization gives Decidim a list of eligible residents, usually as a file the platform checks against during registration or authorization. No external identity provider is involved, so the platform itself holds the verification data and the deployment is a single Decidim application with its PostgreSQL database and file storage. This fits small local processes where the eligible population is known and the stakes of a fraudulent vote are low.
- Integration points: Decidim's authorization handlers compare participant input with the uploaded census. Confirm the exact handler behavior and file format against the Decidim version you plan to run.
- Where verification data lives: The census file and the matching records sit in the Decidim database and attached storage, so they fall inside the same backup, restore and access controls as the rest of the platform.
- High availability: A single node with a tested database backup is often enough for a short voting window. Ask the implementer how restore time is tested before the vote opens.
- Upgrades: Plan each minor version step with a database backup first, because the Decidim update guide requires moving one minor version at a time.
- Data minimization: Keep only the fields needed for matching and delete the raw census file when the process closes, if your records rules allow it.
Check with your legal team who may hold the census, how long it may be kept, and whether a single-node design meets your availability expectations for the voting period.
When only government-verified identities may vote, Decidim can authenticate through an OpenID Connect or SAML broker. Keycloak sits between Decidim and the national eID or upstream identity provider, using identity brokering to accept the external login and pass a verified identity back to the platform. Decidim's social login support is built on OmniAuth, so a custom strategy is added for the broker. The identity layer then becomes a critical service, because a Keycloak outage stops all voter logins.
- Integration points: Keycloak brokers the eID or upstream provider, and Decidim receives the claims through a custom OmniAuth provider. Confirm which claims the eID scheme releases and whether they match what the authorization handler needs.
- Where verification data lives: Keycloak holds session and federation state, while the verified attributes Decidim stores are the ones you choose to persist. Limit what is copied into the Decidim database.
- High availability: Keycloak documents a single cluster, optionally spread across availability zones, and a multi-cluster design. Both supported HA designs need a synchronously replicated database. Keycloak supports PostgreSQL 14 to 18 among its production databases, and the choice should be confirmed against the version you deploy.
- Kubernetes operations: The Keycloak Operator is installed through Operator Lifecycle Manager, and it is strongly recommended to use manual approval mode for operator updates to avoid unintended automatic upgrades.
- Schema changes: Keycloak migrates its schema automatically at startup by default. Large deployments can apply the SQL manually, as the upgrading guide suggests.
Ask the eID provider for its onboarding terms and the broker's support lifecycle before choosing the Keycloak version and topology.
Universities and employers often already run a directory and SSO service that knows who belongs to the community. The participation platform then accepts logins from that directory, and verification becomes membership checking rather than a national identity check. The pattern works well for student or staff votes, but eligibility depends on the directory being accurate, so the directory owner becomes part of the design.
- Integration points: Keycloak can federate an existing LDAP or directory and broker the login to Decidim over OpenID Connect or SAML. Confirm which group or attribute marks eligibility, such as enrolment status or faculty membership.
- Where verification data lives: Group membership stays in the campus or employee directory. Decidim should store only what it needs to enforce one person one vote, not the full directory record.
- High availability: The identity layer usually sits on shared campus infrastructure. Ask whether that infrastructure already meets the synchronous database requirement for Keycloak HA, or whether a separate database cluster is needed.
- Governance: Agree in writing who may change group membership during a voting window and how departures are handled, since these changes can alter eligibility mid-process.
- Testing: Run a test login for each eligible group, including accounts that should be excluded, before the process opens.
Confirm with the directory owner how eligibility attributes are maintained, and document the rules for the period when a voter's status changes.
Rollout phases for a verified voting process
The sequence moves a verified voting process from agreed eligibility rules to a bounded pilot and a reviewed go-live, with a written output at each phase. Durations depend on the written scope, so the plan is fixed with the partner before any build starts.
Agree eligibility rules and census source
The organization's election or consultation owner, legal counsel and data protection lead define who may vote or sign, which census or register is authoritative, how it is refreshed, and what happens to people who move, die or lose eligibility mid-process. DeployOpen documents these rules with the client and records who approved each one. The step closes when the signed eligibility rules and a data sharing agreement for the census source exist, because every later control depends on them.
Select identity source and test eID integration
The team confirms which identity source will vouch for participants, such as a national eID scheme, a municipal login or a Keycloak realm fronted by an approved identity provider, and confirms with that provider's owner that the integration is permitted for this use. DeployOpen then connects Decidim to the identity source through OmniAuth in a test environment and checks the claims returned for identity, residence and age. The output is a set of integration test records showing each claim, the expected value and the observed result.
Configure authorization handlers and one person one vote
The team configures Decidim's authorization handlers so that a participant is verified against the agreed rules before they can vote or sign, and sets the rules for duplicate identities across providers. DeployOpen writes tests for one person one vote, including repeated attempts, parallel sessions, and a person who authenticates through two different methods. The step closes with a test results report that lists each case, the outcome and any defects fixed, and that report is kept with the release record.
Test accessibility and security of verification forms
Verification, census upload and voting screens are tested for accessibility against the WCAG 2.1 Level AA criteria that apply to the entity's obligations, and for security, including authentication flows, session handling, input validation and access control on census data. Findings are logged with severity, owner and fix date. The output is an accessibility test report and a security test report, with retests showing that high-severity findings are closed before the pilot starts.
Run a bounded pilot process
The organization runs one small, real but low-stakes process, such as a single assembly consultation or a limited budget round, using the production-like configuration. Staff verify the census refresh, the eID or SSO login, the voting result and the deletion or retention of verification data as set out in the rules. The pilot closes with a written pilot report that lists incidents, support requests, data issues and the decisions taken to change the configuration before go-live.
Go live and run a post-launch review
Before go-live, the team signs off the final configuration, the access roles, the monitoring and the incident contacts, and confirms the Decidim version and patch level against the security support policy. After the process closes, DeployOpen and the client review turnout data, verification failures, appeals and retention actions, and update the eligibility rules and tests for the next process. The output is a go-live sign-off record and a post-launch review that feeds the next release cycle.
Enforcing one person one vote without keeping more identity data than needed
The core control is one verified identity per voting right, and the design question is how much evidence you need to prove that without storing it. In a Decidim process, verification is handled by authorization handlers that run before a participant can vote or sign. Each handler is a decision: a census match, an eID or SSO assertion, or a postal code check. Set the handler per space so that a budget vote, a consultation and a petition each require only the proof their legal basis allows. Enforce uniqueness at the level of the verified identifier, not the display name or email address, so one person cannot create several accounts and vote more than once. Duplicate detection on census matches should flag records that resolve to the same person, and the rule for handling a flagged record (reject, hold for review or accept the first) must be written down before the census is loaded.
Vote locking is the second control. Once a participant votes, the record should be bound to the verified identity and closed to further changes for that phase, so that the unique-identity check and the vote cannot be decoupled by editing data later. Keep the link between person and vote as narrow as the process allows. A common pattern is to store a keyed hash of the verified identifier, using a secret kept outside the database, so administrators can detect duplicates without reading the underlying national number or census row. Confirm with your implementation partner exactly which fields Decidim writes to the database for each handler, including any fields added by a custom handler, because the default configuration may retain more than your design intends.
What you keep is a legal decision, not a technical preference. The organization's legal basis for the process determines whether raw census data, eID attributes or hashes may be retained, for how long and who may access them. Document the retention period for each verification artifact, the deletion or anonymization step at the end of the process, and the access roles that can view duplicates. Test the deletion step on a staging copy before launch, and confirm that backups, logs and file storage follow the same rule. Public disclosure of results should be designed separately from the identity data. Your data protection officer or legal counsel should sign off on the retention schedule before launch, and the sign-off should be filed with the process configuration.
What auditors and regulators ask for from verification records
This table lists the records an assessor is likely to request for a verified voting or signing process, the component that produces each record, and what the team should confirm before the process opens. Use it to plan which logs, exports and test reports to keep from day one. DeployOpen prepares this evidence, but independent auditors issue any assessment.
| Evidence item | Produced by | What it shows | What to confirm |
|---|---|---|---|
| Authorization handler configuration export | Decidim organization settings and authorization handlers | Which verification method gates voting, signing or proposal creation in each space | Export is taken after each configuration change and stored with a change date |
| Keycloak realm and client configuration | Keycloak realm, OIDC or SAML clients and identity brokering settings | Which identity provider or eID broker issues the identity assertion Decidim accepts | Realm export is versioned, secrets are excluded and the Operator manages client resources |
| Census import records | Census upload step and the import job in Decidim | Which file was loaded, how many records were matched and which were rejected | Source file hash, import timestamp, operator name and the retention period for raw census data |
| Admin access logs | Decidim admin interface, Keycloak admin events and the PostgreSQL host | Who changed verification rules, census data or user roles, and when | Log forwarding to a central store, retention period and who can read the logs |
| One person one vote control records | Decidim authorization uniqueness checks and vote tables | How duplicate identities were prevented and how vote counts were reconciled | Test results showing a second attempt with the same identity is refused |
| Decidim update and patch records | Operator change log and the Decidim release notes | Which version runs in production and whether it sits on the supported 0.32.x or 0.31.x line | Dated upgrade record, one minor version at a time, and patch timing against the disclosure windows |
| Backup and restore test records | PostgreSQL backup tooling and the operations runbook | That the database and uploaded census files can be restored to a known state | Last restore test date, the person who ran it and the result |
| Accessibility test reports for verification forms | Testing team using the site's custom theme and sign-in pages | That registration, eID and code entry steps work for keyboard and assistive technology users | Report covers every verification step, not only the home page |
How much does verified voting cost and what does the work need from us?
What drives the cost of verified voting on Decidim?
The cost follows the written scope, and four factors move it most: the number of identity sources, the size and quality of the census, the effort to integrate government eID or single sign-on, and the depth of testing. Each identity source adds configuration, data mapping and test cases. A clean census file with agreed fields costs less to load and reconcile than a set of spreadsheets from several departments. Hosting choices also matter, because the identity provider, the Decidim application and the database each need capacity, backups and monitoring. No price list is published, so ask for a quote that lists each identity source, each integration and each test cycle as separate line items.
Which verification costs are one-time and which recur?
One-time work usually includes the design of authorization rules, the census import, the eID or single sign-on integration, security testing before launch and the first deployment. Recurring work includes applying Decidim and Keycloak security patches, running minor-version upgrades, monitoring the identity service and keeping backups tested. Decidim supports only the last two minor versions with security updates, so an upgrade plan is a standing cost, not an option. Keycloak also ships releases several times a year, so the patch cycle should be budgeted from the start. Ask the partner to separate these two groups in the quote and to state what a retainer covers.
How long does a verified voting setup take?
The timeline is set by the written scope, and this page does not give a duration. The schedule depends on how many identity sources must be connected, whether the eID provider has a test environment, how clean the census is, and how many rounds of acceptance testing the election rules require. Delays most often come from waiting on external contacts rather than from the software. Agree on a dated plan that names who must respond, by when, and what happens if a dependency slips. Ask the partner to show the critical path before work starts.
What does our team need to supply for verified voting?
Your team needs to supply three things before build work starts. First, written eligibility rules that define who may vote or sign, including age, residence, and any exclusions, approved by the legal or election authority. Second, a named census owner who can answer questions about data quality, update frequency and the source system. Third, contacts at the identity provider, such as the eID operator or the SSO team, with authority to approve test access and production configuration. Also confirm which data fields may be used for verification and who signs off on retention. Missing eligibility rules are the most common reason the scope changes mid-project.
Can our internal team set up verified voting without a partner?
A capable platform team can deploy Decidim and Keycloak internally, but the work is broader than installation. It includes configuring Decidim authorization handlers, mapping identity attributes, testing one person one vote controls, hardening the identity service, planning backups and running patch cycles on two open-source products with different release calendars. Decidim's update guidance asks teams to upgrade one minor version at a time and to back up the database first, which needs a rehearsed process. Assess your staff against these tasks, and consider a fixed-scope engagement for the build with an internal owner for operations. DeployOpen implements, hardens, backs up, upgrades and documents self-hosted platforms in your own infrastructure.
Do we need a database and high availability plan for the identity service?
Yes. Keycloak supports several production databases, including PostgreSQL in versions 14 to 18, and its documented high availability designs require a synchronously replicated database. The development file database is for testing only and must not be used for live votes. Ask the partner which database and availability model they will deploy, what the failover test covers, and how the cost of the replicated database is billed. Your infrastructure team should confirm the hosting location and recovery targets before the quote is final.
What evidence should a verified voting engagement deliver?
Ask for a documented deliverable set that your auditors and legal team can review. It should include the authorization configuration, the census import procedure, the identity integration design, the test results for one person one vote and eligibility checks, the backup and restore test records, and the upgrade runbook. DeployOpen prepares systems, controls and evidence for compliance assessments, but it does not issue audit reports or certifications, so independent auditors and certification bodies must still assess the outcome. Confirm early which evidence your assessor expects.
Which parts of verified voting cost less when we prepare early?
Preparation reduces the most expensive rework. Clean census data, documented eligibility rules and early contact with the identity provider remove the three largest sources of change requests. Decide which verification data you keep and for how long before configuration starts, since removing fields later means reworking data flows and tests. Agree on the test cases with the election authority so acceptance does not restart. Early preparation rarely reduces the platform licence cost, which is zero for Decidim and Keycloak, but it often reduces engagement hours.
Questions to put to an implementation partner on identity
Ask the partner which eID and SSO integrations they have built and tested against Decidim, and in what form. For each one, ask whether the integration runs through an OmniAuth strategy or a custom authorization handler, which Keycloak realm or broker configuration it depends on, and what test evidence exists for the login, callback and attribute mapping steps. Ask for the list of identity providers in a live environment, not a demo, and confirm which of them your own government or national eID provider has been connected to. If the partner cannot name a tested integration for your identity source, treat that as a scope item to price and test, not an assumption to accept.
Ask how census data is matched and deduplicated. Request the matching keys, the normalization rules applied before comparison, and how the partner handles the case where one person appears under two records or two people share a name and date of birth. Ask which fields are stored on the participant record after verification and which are discarded, and whether the verification outcome is recorded as a flag or as the underlying source data. Ask how the partner keeps one person, one vote enforced across phases, components and any paper or in-person channel, and how a duplicate or disputed match is resolved and logged. Ask for the written retention period for each category of verification data and who approves changes to it.
Ask how upgrades will follow Decidim's rule to move one minor version at a time, and how that plan interacts with the Keycloak release cadence. Confirm that the partner will read each Decidim upgrade guide and back up the database before each step, and that Keycloak breaking changes are reviewed and enabled deliberately, since they are opt-in. Ask how the partner will meet Decidim's 2-month window for standard security patches and 4-month window for critical ones, what monitoring feeds them, and who is on call when a patch falls inside an active voting period. Finally, ask how the fixed scope and acceptance tests are written: the list of identity flows, duplicate-voting scenarios and data retention checks that must pass, who signs off, and what happens to the contract if a test fails.
Official sources for Decidim and Keycloak identity setup
Where do I find the official Decidim guide for social login providers?
The official Decidim social providers documentation explains how Facebook, Twitter, Google and Decidim-to-Decidim OAuth 2.0 login are enabled, and how they can be set globally or per organization. It also covers how to add any other OmniAuth strategy as a custom provider, which is the usual route when a government eID or corporate SSO must be connected. Read it before writing the authorization design, because the provider list determines how much custom OmniAuth work the engagement includes. Confirm each provider's configuration keys against the version you plan to run, since the 0.31 and 0.32 branches differ. Start with Decidim social providers.
Which Decidim installation documentation should my engineers follow first?
The Decidim installation documentation describes two paths: a manual Rails application install or a Docker-based setup. Production configurations also need background jobs (ActiveJob), file storage (ActiveStorage), SMTP, maps and geocoding, and social login providers, so plan those services before the first deployment. The manual guide lists the runtime versions for each branch. For v0.32 that means Ruby 3.4.7 and Node 22.14.x, and for v0.31 Ruby 3.3.4 and Node 22.14.x. Your team should confirm the operating system and PostgreSQL versions in the manual guide against their own base images. Start with Decidim installation.
How do I report or track a Decidim security issue and patch window?
Decidim's SECURITY.md defines how vulnerabilities are reported. Reports go to security@decidim.org or through GitHub Security Advisories. The file also sets the disclosure grace periods: implementers get 2 months to apply patches for standard vulnerabilities and 4 months for critical ones before details are published. Only the last two minor versions receive security updates before version 1.0, currently 0.32.x and 0.31.x, so an identity deployment on an older branch carries unsupported risk. Your operations plan should record which branch you run and who watches the advisories. Read the policy at Decidim SECURITY.md.
Where is the official Keycloak Operator installation guide?
The Keycloak Operator documentation covers three installation routes: Operator Lifecycle Manager (the recommended method), kubectl, and an experimental Helm chart. The Operator manages Keycloak, KeycloakRealmImport, KeycloakOIDCClient and KeycloakSAMLClient custom resources, which lets realms and clients live in version control. The documentation strongly recommends manual approval mode for operator updates, so an upgrade does not happen unannounced in production. Plan a change window for each Keycloak minor release, since the project plans four minor releases a year. Read the guide at Keycloak Operator installation.
What does the Keycloak high availability documentation require?
The Keycloak high availability overview describes three architectures: a single cluster optionally spread across availability zones, multi-cluster deployments (v2) without external Infinispan, and the deprecated multi-cluster v1 that used a separate Infinispan cluster per site. Both supported designs need a synchronously replicated database. That requirement affects hosting and cost more than the Keycloak license does, so ask your infrastructure team to confirm whether they can provide it in your data centers or cloud region. Test failover before the first election, because a voting outage on identity verification is hard to explain. Read it at Keycloak high availability overview.
Which databases does Keycloak support for production, and which should I avoid?
The Keycloak database guide lists MariaDB, Microsoft SQL Server, MySQL, Oracle Database, PostgreSQL (14 to 18), EnterpriseDB Advanced, Amazon Aurora PostgreSQL and Azure SQL as supported production databases. The default dev-file database is for development only and should never hold identity records for a voting process. Choose the database your organization already backs up, monitors and restores well, and confirm its version is in the supported range. Keycloak applies schema migrations at startup by default, but the upgrading guide suggests manual migration for large deployments, so ask who will review the SQL. Read the guide at Keycloak: Configuring the database.
Can my team set up Decidim and Keycloak without an implementation partner?
A team with Rails, PostgreSQL, Kubernetes and identity experience can work through these guides alone, but the hard parts are the integration decisions, not the install steps. Those include mapping verified attributes to Decidim authorizations, deciding what verification data to keep, testing one person one vote controls, and rehearsing upgrades one minor version at a time with database backups. Decidim's update documentation requires upgrading one minor version at a time and backing up the database first. A partner work scope typically covers these tasks in a written, fixed scope. Ask any partner to show which of these steps are included and how their deliverables are verified.
How DeployOpen scopes and supports verified participation
This sequence turns a verification requirement into a written scope, a Decidim and Keycloak build inside your infrastructure, tested authentication and voting flows, and evidence your assessors can review, with optional retainers after launch.
Define eligibility rules and verification scope
Before any build, DeployOpen workshops with your legal, election and digital teams to write down who may vote or sign, which process types need verification, and whether census data, a government eID or an existing SSO will prove eligibility. The output is a written scope document listing each process, its eligibility rule, the data each check needs and the assessment evidence you expect to hand over. Nothing is built until you approve this document, and it becomes the basis of the fixed-scope agreement.
Confirm the identity source with its owner
DeployOpen works with your identity owner to confirm how the chosen eID scheme or SSO issues assertions, which attributes are released, and what the identity provider's terms allow you to store. Where a government eID is involved, you confirm the connection terms with the scheme operator, because DeployOpen does not hold those agreements. The output is a short integration specification naming each attribute, its source and its retention limit.
Deploy Keycloak and Decidim in your infrastructure
DeployOpen installs Keycloak as the identity broker and Decidim as the participation platform inside your cloud accounts, data centers or air-gapped network, using the install method your operations team prefers. Keycloak's supported production databases and high availability designs are chosen against your hosting model, and Decidim's background jobs, file storage, SMTP and geocoding services are configured for your data location. The output is a running staging environment with documented versions, configuration and access controls.
Build authorization handlers and one person one vote controls
DeployOpen configures Decidim authorization handlers for census matching or eID checks, and adds the controls that stop one person from voting twice, such as a single verification record per identity and a rule that ties each vote to one authorized participant. Where you use census uploads, the handler is tested against sample files that DeployOpen creates, not your live register. The output is a tested set of handlers with a list of the checks each one performs and the failure messages residents see.
Test authentication and voting flows
DeployOpen's security testing team tests the login, verification and voting paths, including attempts to vote twice, reuse expired sessions, tamper with eligibility claims and reach restricted spaces. Testing covers the application and its APIs as well as the Keycloak configuration and redirect settings. The output is a findings report with severity ratings, fixes applied in staging and a retest confirming each fix before go-live.
Set retention rules for verification data
Your legal team decides which verification data must be kept, for how long and for which purpose, and DeployOpen configures Decidim and Keycloak to match, including what is stored after a check succeeds and what is discarded. Data stored only as proof of a completed check is documented separately from personal data needed for a dispute. The output is a retention schedule and matching configuration settings, which you should confirm with your data protection officer.
Prepare evidence for assessments without issuing audit findings
DeployOpen assembles the configuration records, test results, access logs design, change history and operating procedures your assessors will ask for, and maps them to the controls you are assessed against. DeployOpen does not issue audit reports, attestations or certifications; independent auditors and certification bodies do that work. The output is an evidence pack organized by control, with gaps listed for your compliance lead to close.
Agree optional retainers for upgrades and testing
Once the platform is live, you may agree a retainer covering Decidim and Keycloak upgrades, security patch application within the windows the upstream projects publish, and continuous testing of voting flows. Upgrades follow each project's one-minor-version-at-a-time rule and start with a database backup. The output is a written support agreement stating what is covered, how requests are logged and how upgrades are scheduled around your election calendar.
