Repository navigation
Replies: 19 comments 28 replies
|
FTR, this is the JSON Schema for Workflows: Where the main properties are:
Based on this configuration, workflows are started as follows:
For testing purposes, you can set the server config option For the first iteration, the goal was to provide a set of capabilities to allow administrators to detect and act on inactive accounts. To achieve that, the following built-in steps can be configured within a workflow:
Future release will introduce other built-in steps to aid in onboarding and offboarding users, such as join/leave groups, As for the events that can trigger a workflow, the following are supported in this first release:
The conditions that can be used to filter the resources that will be affected by a workflow include:
|
|
We need to update the schema. For instance should replace
|
|
The proposal looks great! I'd suggest including the schema versioning to the JSON. Perhaps something like this: {
"version": "v1", <-- Here's the version!
"type": "object",
"properties": {
...
}
}Versioning schema from day 1 will make it easier to evolve it. |
|
Why does the workflow need to set?: |
|
It really doesn't - it was mandatory a while ago but with @pedroigor 's latest changes to the JSON definition it is no longer the case. |
|
Are we planning to get rid of: That still makes no sense to me. |
|
This will be replaced with the |
|
Are we planning to update: This is more clunky than we discussed |
|
Yes, idea is to have just |
|
JSON sucks, are we planning to support YAML? |
|
Yes - this is one of the issues in the roadmap - whether it will be in Milestone 2 or 3 is yet to be defined :) |
|
Having to escape |
|
Good point - I'll look into the grammar and see if I can get rid of the whole double quotes or at the very least switch the single quotes to prevent having to escape these characters in the config. |
|
If I understand correctly, workflows are event-driven. So, what if we want to add a workflow to deactivate inactive users to an already old installation of Keycloak that's configured to delete events after a specific period? In this setup, inactive users created before that period won't have any events in the |
|
@bahaa Idea in this case is to enable the workflow for existing resources. The resources that match the workflow's conditions will be bound to the workflow as if a login event was received, this way enabling you to force the assignment of the workflow if they don't become active again. |
|
We will probably have an action in the UI to trigger this action - probably an async operation as it can time consuming to locate all users depending on the amount of users in the DB and how complex the conditions are. |
|
So a more broad answer to your question is that Workflows can be automatically enabled based on events, but it is also possible to trigger them "manually" via an enpoint call |
|
@sguilhen Thanks for your reply. What about adding a feature to trigger the workflow on missing user events. For example, admins can create a workflow that get triggered on missing I believe something like that can be useful for most old Keycloak installations. I believe most installations configure Keycloak to delete events after a specific period, and most inactive users stay inactive forever. |
|
We've been thinking about some ways to handle the inactive users. One way would be to create a workflow that tracks the active users, give it some warm up time (a couple of weeks, a month maybe) so that all your active users trigger the workflow, and then create another workflow that attaches to all users who have not activated the first workflow (i.e. the condition would be the lack of association with the first workflow). This second workflow can have a step that is triggered right away to disable or even delete these users, but it wouldn't be activated on a particular event. An admin would have to select it and then apply it to all eligible resources. There are certainly other ways to approach this. Looking for stored login events might work in some installations, depending on whether they store these events and for how long. Perhaps a condition that says "user-older-than(30d) AND user-event-missing(USER_LOGIN, 20d)" to convey you are looking for users at least 30 days old who have not logged in in the last 20 days. And then you can add a step that removes those users right away. But again, there won't be a particular event you would be listening to in order to identify these stale users. We will keep thinking about ways to handle this situation, perhaps adding some suggestions in the documentation, but I think we won't have a one-size-fits-all solution for this as the conditions vary greatly across deployments. |
|
If a user is being notified, disabled and deleted - can we get some regular events of that operation? Im my first test, I didn't see any event where I can listen to in a custom listener. This is useful if I want to notify other systems about e.g. a user deletion or being disabled. |
|
You can listen for deletion if your listener is handling provider events and the Before solving this problem, we need to review the event subsystem in Keycloak to make it more consistent. Today we have at least 3 different types of events and, sometimes, they overlap with each other. Also, some events, like user/admin events, which you are probably interested in, are very specific to the Admin API or authentication flows, making it hard to leverage them in Workflows without duplicating code/logic when firing events. IMO, steps should not worry about programmatically firing events whenever executing operations or changing the state of a realm resource. It makes a lot of sense to have those workflow-specific events, and in the meantime, while we don't review events in Keycloak, it can help to achieve what you want. Not the best because you will need to listen for a user/admin plus the workflow event. |
Yes, unfortunately it's not the best. It scatters event handling over several places. But at least... something. |
|
It seems that the |
|
I guess it is because it is an anonymous class. An |
|
Unfortunately, it doesn't. That's my code: I never see the "UserRemoved event: ..." message in the logs. |
|
When a user is being disabled while having an existing session, the session(s) will still exist and being active. Is this intended? |
|
I think the way the step is working is consistent with what happens when an admin disables a user in the admin console. Existing sessions are still active but any attempt to login or refresh a token will fail for this users. Maybe in this case it would be better to have a separate step to terminate the active sessions, with the possibility to also trigger the backchannel logout in the process. Then the workflow would have 2 separate steps to handle user disabling and session termination. |
|
Yeah, steps should address a single and specific concern so that you can combine them to achieve your goals. IMO, it is a key design principle. |
|
Thanks, understood. |
|
I'd like to contribute the separate step you suggested here. The idea is a steps:
- uses: disable-user
- uses: logout-user
with:
include-offline-sessions: trueDoes this match what you had in mind? If so, I'll open an issue and send a PR. |
|
Opened #54231 for this. I'll send the PR next. |
|
There's a small, but essential typo in the blog post, I provided as PR: keycloak/keycloak-web#655 |
|
Indeed, thanks for spotting and for the PR! |
|
Is there anything planned, that an admin can see at a user directly that there's a current active workflow and when which steps will be executed? This could provide a better overview at a user, if there's something going on and when this user might be deactivated/deleted. |
|
I've thought about adding some tab to the user's details page where you would be able to see the workflows currently associated with the user, or the steps scheduled to run for that user. We will need to figure out the details though. Do you envision something different for that? |
|
That's the kind of information I'd expect, nothing different. 👍 |
|
Hi, i came here to thank you for this feature it sounds really nice and promising :) We currently have an inhouse built tool which manages the following workflows:
i guess the first 2 workflows might be able to be handled by a keycloak integrated workflow. e.g. for 1. you already have an event for user created so we might only need something like i guess our workflow 4. is to special or would require too much changes to keycloak but if we could get rid of the other once and replace them with keycloak integrated workflows sound quiet interessting :) If you have any further questions feel free to ping me. Thanks for your work on keycloak :) |
|
Hi @TuningYourCode , thanks for the message! You are right. For 2-3, and likely other uses cases, we will need to add the events that would allow us to trigger a workflow. It is very difficult to foresee all possible use cases, so we will rely on feedback from the community to keep enhancing the list of events available for workflows. Regarding the notify user the step allows for the specification of the message key that should be used when composing the e-mail. So I think it might be re-usable for most use cases. Number 4 has to do with another governance capability - see more on #41350. It is being discussed and I don't yet know how this will integrate with Workflows, but in theory it should be possible to have workflows triggering approval requests upon certain events. |
|
@sguilhen we've looked at the workflow feature and we figured, that a step for sending out webhooks would be a great addition, because users would be able to integrate keycloak more deeply and could define custom events as of their choosing or could just send every user/admin event to an external ressource (without using a plugin for this feature) whats you opinion on adding such a feature in the future? also relevant: #41065 |
|
@paulwer I did look into this not too long ago - I think I was reading the issue you've linked. Using workflows for that is definitely a possibility in my view. You basically need a step implementation that has the configuration needed to forward selected events to external endpoints. It could even sign the webhooks if needed. So basically, workflow activates on the events you're interested in, then the webhook step would forward them to the configured endpoints. I am just not sure if this is the way we want to address the webhook story in Keycloak or if a dedicated feature would be better in the long run. Perhaps the workflow approach would be more than enough and a relatively easy task that leverages the workflows engine and delivers a high-valued feature quickly. |
|
@sguilhen after some thought I would suggest a webhook system first for keycloak user and admin events, which would be more predictable and most likly the use-case 95% the userbase needs. From a techn. perspective this system would focus on deliverability and would leverage the existing event system. features are retries, hmac encrypt, delivery types (http, file, fifo api queue(pull by client)...), maybe logs. => good reference is svix, but i do think this could start very small just with http to not complicate things 😄 Afterwards an integration in workflow engine with an additional step in workflows allowing to trigger custom events which are now handled like the other events. => workflow step would "just" trigger this custom event and would not care about where it goes => custom event could just be admin events with an custom name and a custom payload maybe custom events would be a good addition for some folks regarding monitoring/reporting and maybe some external application could/would rely on such an event system for other use cases as well. Edit: Here is my suggested solution as an PR: #48168 |
|
I'm doing some experimentation with Workflows and I see some places where I would really like to see some broader capabilities. For example, I would like to be able to have a conditional for things like
Right now, this does not seem to be possible? Correct me if I am wrong please. |
|
Hi @InfoSec812 . You are right - out of the box this is not possible. However, it should not be hard to add an email condition provider - perhaps with regex support so you can match specific domains, for example, and add them to certain groups. |
|
Hi community
|
|
Hi @kikkauz , good questions.
|
|
The workflow functionality is awesome. I just found myself needing |
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
Hi all,
In Keycloak 26.4 we've introduced a new feature called Workflows, designed to automate administrative tasks such as automatically notifying/disabling/removing inactive users, onboarding, offboarding, among other things. In the first iteration it is focusing on user resources but the plan is to expand the feature so that actions can be taken automatically on other resources - e.g. disable a client or an IDP that hasn't been used to authenticate users for some time.
See out blog post for a walk-through: https://www.keycloak.org/2025/10/workflows-experimental-26-4
It is in experimental stage and we will be publishing a blog post about the current state of it - to be linked here once published. The work and more details about the feature roadmap can be found in the respective epic.
As always, feedback is most welcome! We invite the community to discuss and comment either here or in the epic that is tracking all the work we're doing in this area.
All reactions