search

zitadel / actions

ZITADEL Actions - Easy extensibility with custom code. Think GitHub Actions in an Identity System.
https://zitadel.com
29 stars 6 forks source link

Add `store_last_auth_error.js` example #3

Closed eliobischof closed 1 year ago

eliobischof commented 1 year ago

Depends on https://github.com/zitadel/zitadel/issues/4908

adlerhurst commented 1 year ago

management service will not be added for the moment

fforootd commented 1 year ago

management service will not be added for the moment

Can you please elaborate a little more? Where does the mgmt service not being added? To the action context? If yes why did we decide to do that?

livio-a commented 1 year ago

management service will not be added for the moment

Can you please elaborate a little more? Where does the mgmt service not being added? To the action context? If yes why did we decide to do that?

Yes he meant the api parameter of the actions. This example was added as part of the actions for local users issue, which requested to be able to execute actions the on local authentication like we already have for external authentication, a.o. I want to be able to create the same actions as we have on external authentication. While it would be nice to expose the management service / api directly in the actions, it will take some more effort to ensure the security, e.g. prevent broken auth.

As far as I know the mgmt service was mainly added for e2e testing purposes in the beginning of the PR.

fforootd commented 1 year ago

management service will not be added for the moment

Can you please elaborate a little more? Where does the mgmt service not being added? To the action context? If yes why did we decide to do that?

Yes he meant the api parameter of the actions. This example was added as part of the actions for local users issue, which requested to be able to execute actions the on local authentication like we already have for external authentication, a.o. I want to be able to create the same actions as we have on external authentication. While it would be nice to expose the management service / api directly in the actions, it will take some more effort to ensure the security, e.g. prevent broken auth.

As far as I know the mgmt service was mainly added for e2e testing purposes in the beginning of the PR.

OK thanks that gives it some context.

I think we should create a safeguard in actions where users can enables "secrets" in apis with either read or write access. But lets figure this our seperatly.

livio-a commented 1 year ago

OK thanks that gives it some context.

I think we should create a safeguard in actions where users can enables "secrets" in apis with either read or write access. But lets figure this our seperatly.

Yes "secrets" would also provide a way of setting an explicit context / executer (i.e. service account). We currently have an implicit context of org level / ORG_ADMIN and have all the authorization in the grpc service. Direct access to the management service would mean you could bypass that and e.g. access / manipulate information outside on other organisations. (Which is fine if you have the grant to do so, e.g. with a PAT of a service account in the secrets of the action.

eliobischof commented 1 year ago

I agree we have to ensure that validations and permission checks run. But I added the mgmt server not because of the e2e tests, ofc 😅. I think it's very inefficient for action devs (users) and api devs (us) to add more and more api contracts and implementations when we already have everything needed. Unfortunately the first trial didn't work as implemented, but IMO we should switch as fast as possible to a harmonized API for RPCs and actions.

fforootd commented 1 year ago

think it's very inefficient for action devs (users) and api devs (us) to add more and more api contracts and implementations when we already have everything needed.

Yes I think at one point we want to expose everything and have a safeguard for secrets (i.e you need to explicitly need to allow that)