u/isro44

Hey everyone,

When extending Keycloak to store custom tenant metadata or custom token attributes inside its embedded Infinispan cache, you eventually need to decide on a marshalling strategy.

Keycloak's Infinispan layer uses ProtoStream (Protobuf) as its default serialization framework. However, there is no built-in Keycloak configuration flag or SPI that lets you simply mount a directory of arbitrary .proto files and register them into Infinispan's SerializationContext at startup.

In practice, we usually see three approaches:

1. Baking .proto files into custom Docker images: Works, but couples your schemas to the image lifecycle and makes every Keycloak patch update a pain.
2. Falling back to application/x-java-object (POJO) storage: Works fine for single-node setups, but in distributed/replicated production clusters, cross-node marshalling often brings you right back to requiring a registered ProtoStream schema.
3. Spinning up external Infinispan clusters: Gives you full control, but introduces extra stateful infrastructure, network latency, and maintenance overhead.

To solve this for our deployments, our Senior DevOps Engineer built a small extension that uses Infinispan's native SerializationContextInitializer discovered via Java's ServiceLoader. It scans a mounted directory for .proto files, combines them into a single FileDescriptorSource (handling cross-file import dependencies), and registers them in one pass at startup, before caches serve traffic.

For those running Keycloak in production clusters:

• How are you currently handling custom cache entity serialization?
• Do you stick to POJO storage, or have you implemented explicit Protobuf schema contracts across cluster nodes?

We put together a breakdown covering the code pattern, cluster schema evolution, security considerations, and an open reference demo with a Docker test suite: https://keymate.io/blog/keycloak-protobuf-spi

Curious to hear how you are handling custom Infinispan cache objects in Keycloak at scale.

We've been working on a pattern for AI agent authorization that sits between your API gateway and Keycloak, and wanted to share the architecture for feedback.

The core problem: classic API gateways handle routing and basic token validation, but they don't evaluate the contextual conditions that matter for agentic systems; who the agent acts on behalf of, what the tenant context is, what the risk score is at the time of the request. Pushing all of that into Keycloak policies becomes unwieldy fast.

The approach we landed on has three components:

• Access Rules: YAML-based declarative policy artifacts with a single CEL condition expression covering all relevant contexts
• Access Rule Engine: evaluates DENY decisions locally before the request ever reaches Keycloak; GRANT decisions still pass through to Keycloak as the final authority
• kmctl authz: a design-time CLI for validating, simulating, and explaining policies before they hit production

The "two-layer identity" part is where it gets interesting for Keycloak users specifically: the agent has its own identity (the software client), but it also carries an actor identity, the business user it represents. The authorization decision needs to evaluate both simultaneously. Keycloak's token structure supports this, but you need the intermediate layer to act on it correctly.

Full writeup with live demo (one GRANT, four DENYs, including a social engineering attempt): https://keymate.io/blog/fine-grained-authorization-for-ai-agents-how-it-works-in-production

Happy to discuss the Keycloak integration specifics in the comments.

Hi everyone,

When an AI agent sits between the user and downstream systems, authentication alone stops being the hard problem. The harder question is what data the agent can reach, under what conditions, and on whose behalf answered in a way that's explainable, testable, and centralized.

The post covers what the IAM ecosystem has shipped around this (Transaction Tokens for Agents, XAA, RFC 9728, AAuth, OWASP LLM and Agentic Top 10, Microsoft's Agent Governance Toolkit), maps the gap that still remains, and sets the stage for Part 3, where the series moves from the problem to a concrete approach.

Link: https://keymate.io/blog/why-ai-agents-need-fine-grained-authorization

Cheers

Hey everyone,

Standard Keycloak images are great out of the box for dev, but when moving to enterprise production, compliance teams usually flag the base image vulnerabilities (CVE noise) and standard root execution policies.

We’ve been working on production-ready IAM infrastructure at Keymate, and we had to harden our upstream Keycloak container images to meet strict corporate standards.

Instead of keeping this internal, we mapped out our entire hardening framework. Here are the core adjustments we made:

1. Base Image Swap: Swapped standard bases for minimalist/distroless alternatives. This alone cut down container scan noise significantly.

2. Hardening Access: Enforced strict non-root execution to mitigate potential container breakouts.

3. Attack Surface Reduction: Stripped out unnecessary shells (/bin/sh) to block common post-exploitation RCE tactics.

4. Security Standards: Aligned the configuration layer with CIS Container Benchmarks and NIST SP 800-190.

We wrote down the detailed technical implementation, architectural decisions, and why this matters for regulatory compliance.

If you are running Keycloak in production, hopefully, this saves your team some time: https://keymate.io/blog/hardened-keycloak-container-image

Cheers