Clarifying System API Users
Hello everyone,
I'm following the Access ZITADEL APIs docs and I'm unclear abotu a couple things concerning the System API configuration, as shown here.
Can anyone confirm that if I provide the SystemAPIUsers with the IAM_OWNER and ORG_OWNER roles that I can create Users and Service Users for an organization I am authorized for as a System User?
By extension, this would also mean that the
AggregateID in the IAM_OWNER and ORG_OWNER memberships are mandatory in the Zitadel runtime configuration, is that correct?ZITADEL Docs
This guide explains what ZITADEL APIs are and how to access ZITADEL APIs using a service user to manage all types of resources and settings.
3 Replies
@Raccine is there anyone that can help clarify this? My team and I are having a lot of trouble with the documentation
Hi @nullsense! :gigipixel:
Can you give me some more insight into your use case? You could possibly use a service account as opposed to a system user for this task. ➡️ https://zitadel.com/docs/guides/integrate/service-users/authenticate-service-users
1. For your first question, yes - You should be able to. However, we wouldn't recommend it ➡️ https://github.com/zitadel/zitadel/blob/d01d003a0326de8ea3102c4b28733322ac9d70cd/cmd/defaults.yaml#L651
2. Yep, this is correct!
Can you also let me know where your team is struggling with documentation? That feedback will allow us to improve our docs!
Hi @Raccine
Thank you so much for getting back to me.
Our use case is that we would like to use the System User to provision some default objects (org, projects, users, system users, roles) upon first instance deployment and have these objects available to the root user. Although we have also looked at Service Users to do this, it turns out that the System User better suits our needs for various other requirements on our end.
What we're finding is that the System User is able to create an organization successfully but fails to create a project successfully. We're not sure if this is a bug or not. It seems related to this closed issue here, but re-setting the orgId in the client (zitadel-go sdk) does not seem to help. We feel we are missing something.
The docs don't seem to mention that setting the
AggregateID in the memberships is mandatory, and there are examples in the internal Zitadel code where it is omitted as well. If it is indeed mandatory, how would we be able to grab this before the organization is created? (Our understanding was that omitting the AggregateID would mean the System User would have access to everything, including being able to create projects et al.)
In the end, we need help identifying how the System User can create these objects.GitHub
Issues · zitadel/zitadel
ZITADEL - Identity infrastructure, simplified for you. - Issues · zitadel/zitadel
GitHub
zitadel/internal/integration/config/zitadel.yaml at d01d003a0326de8...
ZITADEL - Identity infrastructure, simplified for you. - zitadel/zitadel