So far, in my FIWARE DATA SPACE blog series, I've talked about the low-hanging fruit (CKAN), about harvesting, and about how to actually start building something that doesn’t collapse after the first dataset.
But once you have data and shiny catalogs, the next logical question is:
WHO CAN ACCESS WHAT AND HOW DO WE CONTROL IT
That’s where authentication and authorization enter the picture. Or: “WHO GUARDS THE GATES?”
OUR OPTIONS: KEYROCK VS. KEYCLOAK
In the FIWARE world, the “default” suggestion is often Keyrock. It’s lightweight, well integrated with Orion and CKAN, and has been around for quite a while. But when we dug into it for our FIWAREBox Data Catalog-as-a-Service (DCaaS) and Data Space-as-a-Service (DSaaS) FIWARE Data Space setup, we hit a few problems (mildly speaking).
WHY WE FAILED WITH KEYROCK
- Unmaintained → The project isn’t actively maintained. For something as critical as security, that’s a red flag.
- No path to decentralized Auth → In the future, our clients might want to use their own identity providers (federated or decentralized). With Keyrock, there’s no real way to make that work (or we are not aware of it).
- Too simple Authorization → Keyrock handles basic OAuth2 and lightweight RBAC. For anything more complex, you need AuthZForce, which is powerful but adds a whole new layer of complexity.
- Lock-in risk → Imagine building your FIWARE Data Space around an unmaintained component… and two years later you need a feature. You’re stuck.
KEYCLOAK - ANOTHER OPTION
On the other side of the ring, we have Keycloak.
- Actively maintained → Regular updates, strong community, backed by Red Hat.
- Future-proof → Even new standards like OIDC for Verifiable Credentials are already on their roadmap (Keycloak docs).
- All-in-one → Handles both authentication and authorization in a single component, no bolt-ons required.
- Standardized → OAuth2, OpenID Connect, SAML, RBAC, ABAC - pick your acronym, Keycloak supports it.
- Integration ready → Works with CKAN, FIWARE context-brokers (some better than the others), Gaia-X, EU DATA ACT requirements, DCaaS, and DSaaS.
Yes, it’s heavier than Keyrock. Yes, we started first with Keyrock, but changed our mind. But in exchange, you get a future-proof security backbone for your FIWARE DATASPACE. And honestly — in security, we’d rather be heavy than outdated.
| Feature | Keyrock | Keycloak |
| Maintenance | LOW, not actively updated | HIGH, frequent updates and releases |
| Adoption | FIWARE ecosystem, small community | GLOBAL, thousands of deployments |
| Authentication | Basic OAuth2 | OAuth2, OIDC, SAML, federation, VC exp |
| Authorization | Simple RBAC; complex → AuthZForce | Built-in RBAC, ABAC, fine-grained pol. |
| Federation / Decentralized | No | Yes (multiple IdPs, federation) |
| Ease of use | Simple start, limited long-term | Steeper start, better long-term |
| FIWARE integration | Native, lightweight | Needs config, but fully compatible |
| GAIA-X integration | Weak (no federation, no VC path) | Strong (federation, VC roadmap) |
| Risks | High (unmaintained, feature lock-in) | Low (mainstream, evolving) |
CHALLENGES
When we talk about guarding in DCaaS (CKAN + FIWAREBox stack), it’s not just about “WHO HAS THE KEY” but also “HOW MANY TYPES OF DOORS EXIST”.
We began with what felt like a simple premise: close the obvious doors. But every time we thought a chapter was done, another sneaky entrance appeared, and suddenly one more guard zone demanded attention. We keep patching and closing gaps, yet there’s always that nagging feeling - have we really locked everything, or did we just find the next rabbit hole?
Here is the current list, the nine key areas that typically need protection, with a quick look at how Keyrock and Keycloak cover them out of the box:
1. Identities & Sessions (the front door)
- Users, groups, and roles must be properly authenticated.
- Tokens and sessions need to be controlled, including MFA, session lifetime, and refresh tokens.
- Machine/service identities are part of the same equation.
Keyrock: basic IAM, no MFA (out of the box: N)
Keycloak: full IAM with MFA, policies, federation (out of the box: Y)
2. Tenancy & Scoping (who sees which room)
- Organizations and groups in CKAN define visibility of datasets and resources.
- Access can differ at dataset vs. resource level.
- Public vs. private is not just about hiding, but blocking access via APIs too.
Keyrock: orgs/roles, but needs mapping to CKAN groups (out of the box: N)
Keycloak: realms/groups/roles, also needs CKAN mapping (out of the box: N)
3. APIs (all the side doors)
- APIs include CKAN Action/Search/DataStore, NGSI-LD brokers, file storage, harvesters, and webhooks.
- All must enforce the same security as the UI.
Keyrock: needs Wilma PEP proxy for APIs (out of the box: N)
Keycloak: needs API gateway or OIDC proxy (out of the box: N)
4. Usage control & Policy (not just yes/no)
- Beyond “allow or deny”: ABAC, RBAC, rate limits, time-boxed access.
- Policy enforcement is key in data spaces (licenses, consent, contracts).
Keyrock: only basic roles, needs AuthZForce PDP for ABAC (out of the box: N)
Keycloak: built-in authorization services (ABAC, RBAC, conditions) (out of the box: Y)
5. The UI layer (Windows need locks too)
- UI must not pre-render or leak private datasets.
- Dataset listings, download buttons, and dashboards need to respect token scopes.
Keyrock: only tokens, enforcement in UI code (out of the box: N)
Keycloak: same principle, better SDKs for UI, but enforcement still app-side (out of the box: N)
6. Data pipelines & Harvesting (the loading dock)
- Harvesters, ETL jobs, and uploads need authenticated credentials.
- Outbound data syndication must apply downstream policies.
Keyrock: client credentials possible, no special harvester policies (out of the box: N)
Keycloak: client credentials + policy engine, still needs integration in pipelines (out of the box: N)
7. Backoffice, ops & Invisible ports (the boiler room)
- Admin consoles, metrics, health checks, backups, and secrets must be protected.
- Network edges (TLS, mTLS, WAF) are as important as IAM.
Keyrock: weak, only username/password (out of the box: N)
Keycloak: strong, admin roles, MFA, federation (out of the box: Y)
8. Auditability (the cctv)
- Logs of who did what, when, and to which dataset are critical.
- Includes API usage, dataset changes, failed logins, and anomalies.
Keyrock: minimal token logs, no dataset access audit (out of the box: N)
Keycloak: event logging for logins/tokens, not dataset-level (out of the box: Y for auth, N for CKAN)
9. Lifecycle & Governance (house rules)
- Onboarding/offboarding, user federation, consent, and data classification.
- Automation ensures governance scales with the data space.
Keyrock: CRUD only, no federation or automation (out of the box: N)
Keycloak: full lifecycle support, federation, self-service (out of the box: Y)
WHY THIS MATTERS
A FIWARE Data Space is not just about sharing data. It’s about trust, governance, and control.
- DCAAS, CKAN → Catalogs must enforce rules: who publishes, who consumes, under what conditions. Keycloak’s RBAC/ABAC is strong enough for this. But it needs a lot of work.
- DSAAS → Clients don’t want “some” login page. They want integration with their own enterprise systems. Keycloak makes that possible. But it needs even more work.
- GAIA-X ALIGNMENT → Gaia-X pushes interoperability and federated identity. Keycloak is ready; Keyrock isn’t.
DCAAS LOGIN WITH KEYCLOAK
CONCLUSION
In the end, the choice was simple: Keycloak. Not because it’s the easiest to set up (it isn’t), but because it’s the most future-proof, standardized, and safe bet.
With security, you don’t gamble on unmaintained projects or “maybe someday” features. You choose something that works now and tomorrow.
So, WHO GUARDS THE GATE in our FIWAREBox Solutions Data Catalog-As-A-Service (DCAAS) and Data Space-As-A-Service (DSAAS)?
KEYCLOAK DOES.
DISAGREE, COMMENT, OR WISH TO KNOW MORE?
CKAN: OUR FIRST LOW-HANGING FRUIT IN DATA SPACES