Repository navigation
Replies: 5 comments
|
It would be very good to have a Keycloak MessageToUser SPI for custom message rendering, delivery and authentication implementations. As described above this shouldn't be restricted to emails. This approach doesn't require to integrate provider SDKs. It should enable integration with a custom SPI implementation. The EmailSenderProvider.java could be reworked, so that
SPI implementations which send emails rendered at Keycloak and just want to replace the sending protocol or authentication, they should be able to re-use parts of the Keycloak default email delivery implementation (i.e. message rendering based on localized texts, sending the email via standard protocol like SMTP, authentication options like XOAUTH2) |
|
Would delegating messages to an external process that provides a simple REST API work for Keycloak, similar to how Prometheus and Alertmanager are separated? I assume this can introduce some issues with external dependencies and trust / reliability, but it can also make things quite a bit easier to get going, as libraries are language-dependent so harder to write and maintain (fewer users by default) than standalone services. |
|
I would keep it simple : stick with simple SMTP interface.
But also, as Keycloak only needs to send mails, a simple postfix server can perfectly do the job as long as it is properly configured to send mail (spf,dkim,dmarc,dane,reverse dns) Maybe someone in the community will see a need to fork the old/previously opensource version of https://emailengine.app/ and keep distributing it as OSS |
|
how about rfc4422 ? |
|
Let's break this down a bit more; First you'd need the user to supply additional means of contact than email. Then who decide what messages goes where? Is it the realm admin or the user, or both? Final thing of supporting multiple different messaging mechanisms, that's fairly simple really. We should really just add a SmtpMessageSPI or something, probably with no default implementation as there's no standard for that AFAIK. |
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
Current status of this discussion
Implementing XOAUTH2 for Keycloaks outgoing Emails described in #17432 made several ideas and improvements visible. The topic was discussed with serveral participants of the Keycloak DevDay 2025 Hackathon. Needs further feedback, everone is welcome.
Problem description
The abstract topic is: The IAM System has several reasons to send a message to the user of an identity. Keycloak provides Email for several Use-Cases via SMTP-Protokoll which allow sending good old E-Mails to users. There are several improvements in every step.
From a user of an identity, there might be different things a message can be sent to: message-handle
-- Slack
-- ...
When looking into the Details of each of the message-handles there are the protocols these handles accept:
Each protocol supports different authentication mechanisms
For Token based authentication mechanisms we have different ways to gather a token. I would argue to stick to mechanisms that are meant to be used by a machine:
Solution
Assumptions
Build some more explicit ways to allow extensions to the area
Things to keep in mind/requirements
This would create a dropdown with every message provider that Keycloak can find during startup
Each line is self-contained and complete. Behind the scenes there might be libraries or code shared that is part of Keycloak, but things are likely to be more complex than planned.
Any alternative ideas or recommendations? Maybe existing libraries? The available provider-SDKs might introduce a lot of dependencies :(.
Using the build feature might be useful similar to the db selection.
All reactions