The future of actions #6926
Replies: 6 comments 64 replies
-
Are actions on orgs still required?Should b2b customers be able to add actions? => no TODO: discuss why it's risky/not useful |
Beta Was this translation helpful? Give feedback.
-
Validation custom runtimeIs a custom runtime the best way to provide extendability of the behavior of ZITADEL? Currently ZITADEL uses goja to execute ECMAScript code. The code is stored inside ZITADEL. There are currently several flaws in DevX and to fulfill the requirements:
Developers are nowadays used to work with git, deploy their code through ci/cd and deploy small pieces of software like FaaS. ZITADEL behaves differently which results in an overhead. |
Beta Was this translation helpful? Give feedback.
-
Validation ECMA-ScriptZITADEL currently only allows JS as action programming language. Is JS still our preferred language? Should we move to another runtime like WASM? The discussion is only relevant if ZITADEL is the runtime for actions. |
Beta Was this translation helpful? Give feedback.
-
|
I did not see this use case covered in the beginning, but I am working on using actions to modify a JWT to integrate application databases. Right now I am planning on authenticating a user on the database with the JWT signed by Zitadel, however, revocation will require an action which can invalidate that token in the database for a specific user. Generally, I hope that Zitadel can be the single point of truth for any infrastructure integration for the application, and actions may be a crucial part of this. Are actions limited to modifying JWTs, or manipulating Zitadel data, or can they also be used to make API requests to an external database for example? It would be really cool if I could investigate if any risk exists when replaying a jwt, and if api actions can remove that risk. |
Beta Was this translation helpful? Give feedback.
-
|
I have an absolute need to at least add to any claim that already exists. The point of actions is to be able to change the final outcome of what is present in an id_token and access_token. Speaking about aud. If I mutate this claim by completely replacing it, that's on me. My business, my use case, breaks no other user of zitadel. There are some claims that are part of the spec the I should not be able to change. expiration, etc. Everything else should be fair game. |
Beta Was this translation helpful? Give feedback.
-
ConceptIf you have questions or proposals for the concept of the original post feel free to share them in this thread :) |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
-
Discussion is closed. The epic can be found here: #7235
Thanks to all the participants. ❤️
Actions are a powerful feature to customise the behaviour of ZITADEL.
This discussion summarises previous discussions held in different resources. There are multiple open topics which should be discussed in this discussion. Feel free provide your feedback, thoughts and additions :)
Resources
The following links are meant as knowledge base. Please add comments in this discussion instead of adding comments to the resource, except the comment is not action related.
Use cases
#4265 (comment)
Functional requirements
Configuration
and org (TODO: needed?)levelTODO: instance actions run before or after org actions?TODO: policy to disable org actions?Define a timeout per action=> should be implemented in an actionTODO: Define a timeout per "flow"Execution
TODO: do we have to redact fields like pw or disable functionalities?FUTURE: Call other action@adlerhurst's opinion: providing a way like github action's depends-on would be more clearDocumentation
Non-functional requirements
Are actions on orgs still required?
Discussed in #6926 (comment)
=> outcome they are still required on org level. It's easier to have smaller pieces of code for maintenance
Validation of custom runtime
Discussed in #6926 (comment)
=> outcome: ZITADEL will focus on a webhook style approach which gives full flexibility to the maintainers of actions
Validation ECMA-Script
Discussed in #6926 (comment)
=> This discussion is postponed for the moment based on the outcome of [the previous discussion]{#Validatioon-ECMA-Script}.
Vision
This topic describes what further steps can be taken with actions.
What does that mean for settings/policies and proto validations?
Can we get rid of them and define actions for each request? Do we need to provide system level actions?
=> for the moment they will remain as is
Templates
Duplicate of Marketplace?
=> discussion will be picked up after implementation of actions v2
Git integration
Analog github actions, i can run bash in an action or use an already existing action
=> not planned
Marketplace
Analog github actions marketplace
=> discussion will be picked up after implementation of actions v2
Interaction between actions
If we could define inputs/outputs of actions in a "flow" actions could interact with each other
=> not planned
Notes
Disable email sending is assumed to be solved by Session/User API and is therefore ignored in the use cases.
Index
Future
Following topics will result out of the discussions
Concept
Currently there are some actions available on ZITADEL. These actions run in an integrated runtime. This concepts describes the next major versions of actions.
Current actions stay available until triggers or migration paths for existing flows are implemented/documented.
Triggers
Actions are can get triggred at the following points
Runtime
ZITADEL will not provide a built in runtime for actions.
Arguemnts:
API calls
ZITADEL actions will call external API's which process the the input analog to extensions of chat apps. An example flow can be found in this comment. These API calls support REST and GRPC. The request and response messages are defined by ZITADEL. There will be SDKs provided for the most used prgramming languages for easy integration.
Arguments:
Order of execution
As there can be defined actions on organizations and instances the order of execution forces actions of instances to overrule actions of organizations as follows:
Verification of API calls
ZITADEL needs to provide a possibility for actions to verify the API call. As this problem is solved by webhook providers ZITADEL will provide request signatures analog to stripe webhooks.
Action object
The action object describes the call to the API and contains the following fields:
JSONorGRPCActions can be managed with the following calls:
Trigger object
The trigger object describes when actions are executed.
activeorinactiverequest: name of the API callresponse: name of the API callevent: event typeTriggers can be managed with the following calls:
Required changes to meet the concept
TODO
Beta Was this translation helpful? Give feedback.
All reactions