Replies: 2 comments 4 replies
-
|
jFTR – a related discussion with focus only on user events: #8536 |
Beta Was this translation helpful? Give feedback.
-
|
IMHO if we're talking about remote extensions (which implies the service might not be very close to the KC instance), the primary focus should be on async. Real-time remote extensions would be potentially a big bottleneck and might be hard to properly scale. I can imagine async would be more common use case here. From this reason I'm not sure if UI extensions make much sense. |
Beta Was this translation helpful? Give feedback.
-
|
UI extensions makes perfect sense from my perspective, but with a slight different twist. In how I'm thinking about that Keycloak becomes "headless", and there's a UI "facade". So something like: [SPA] ---REST---> [KC] That's already the direction we've gone with admin and account consoles, and makes sense for the login UI as well. |
Beta Was this translation helpful? Give feedback.
-
|
Makes sense, but even in this case that OOTB provided UI SPA should be easily extensible, not to push users to completely write their own custom UI apps for some smaller changes. |
Beta Was this translation helpful? Give feedback.
-
|
+1 If you look at the new account console for example that allows extending, so we already have some precedence for allowing customisation of a SPA type UI. |
Beta Was this translation helpful? Give feedback.
-
|
The way I've tried this in the past was with Webpack module federation. You can have semi-fully-contained modules that would use certain extension points from the main UI to extend it. A module that would for example add a new menu item and change a few things in the server, could register itself as an item and use the server call utilities provided by the main UI to perform the calls. On the Server to Server communication, I do agree that an event based architecture is probably a good way to go, but some other alternatives could provide better abstractions: You could have an interface that would either call code locally or through gRPC (with a persistent connection) seamlessly. |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
-
Hi,
currently, Keycloak is extensible through SPI implementations - java code installed into the keycloak instance. It provides powerfull and performant extensibility, but is heavyweight a bit. It requires good java programming skills and often also deep knowledge of KC internals to write custom extension, bug in the extension can make KC instance unstable, installing/upgrading extensions require instance restarts etc.
So I'd like to start discussion about more lightweight, and cloud native extensibility. It should allow to write external extensions in any language or technology, use common/standardized and cloud native communication protocols, be isolated/asynchronous so KC instance's stability is not affected by unstable extension etc.
So few questions we should discuss:
From my point of view, I see a big potential in Keycloak Event mechanism. We should review and refurbish existing events to cover all important actions/activities, mainly around auth flows and user management. Then we can implement connectors to publish these events to external systems - I can imagine REST webhooks, kafka messages and/or knative messaging.
External extension can be written then easily to consume these events - mainly data analytics and observability extensions would be easy to provide this way. And extensions can also use KC REST API to react to these events and change data in KC.
But I can also imagine extension points which can extend UI - allow to add new steps into authentication flows, provide required actions, customize existing forms (eg. external fields in user registration/update form, user profile field option providers and validators) etc.
And also extension points which add ability to put external risk assessment/approval system into registration and login flows (so they require timely response so flow can continue) etc.
Thanks in advance for your opinions, comments and proposals.
Beta Was this translation helpful? Give feedback.
All reactions