Is it possible to configure IDPs via API?
Or is the Web UI always required? Our team is just evaluating Zitadel as self hosted authentication solution. We would need to configure Zitadel via API though. Is this possible? because i could not find anything in the docs. In the API section i was only able to find a few GET requests.
14 Replies
hi @Jürgen we have V1 IDP APIs that works, we are in the process of transitioning APIs but the above works for now 🙂 no console needed
thanks for the reply! i only look at the v2.. my bad.
hey @Jürgen if this helped, pls mark my answer with ✅ and it will auto close it.
🎉 Looks like you just helped out another community member! Thanks for being so helpful <@1346540274674827395>! You're now one step closer to leveling up—keep up the amazing peer support! 🚀
Hello @Rajat Singh , can you please reshare the link… the url does not exist anymore
Also i would like to know if there is possibility to configure IDP for a specific organisation instead of default organisation
It seems like the link to the "Identity Providers" index page in the api docs isn't working
This is one example endpoint of the V1 IDP API:
https://zitadel.com/docs/apis/resources/mgmt/management-service-list-providers
ZITADEL Docs
List Identity Providers
Btw, I'm currently working with them and I found rather cumbersome the API workflow related to setting up identity providers - is it going to change? Today we must:
1. create an identity provider "template"
2. depending on the current organization login policy:
- if the organization login policy already exists: link the identity provider to the organization
- if the organization login policy doesn't exist yet:
a. make a request to get the instance default login policy
b. create the organization policy, using the default login policy attributes AND the linked idp (or alternatively make another request in sequence to link the idp)
it'd be nice if it was possible to (optionally?) automatically "link/activate" a newly created identity provider to an organization (regardless of the login policy existing or not). Under the hood Zitadel could simply be creating a new login policy (based on the default login policy)
cc @Rajat
hey @bawsky good point but I think it was a design choice of what you are mentioning. Permissions works in scopes, meaning org level permissions to manage anything or related AND instance level policies to manage multipule orgs all at once. In yoiur case, the new IDP will be indeed created BUT will only be allowed to use based on the policy has been set
RIght, but isn't the "delete identity provider" violating that reasoning then? I.e.: right now deleting an organization identity provider that's already linked to the organization works just fine (transparently removes it from the organization login policy and deletes the identity provider in a single request)
https://zitadel.com/docs/apis/resources/mgmt/management-service-delete-provider
It'd be nice if the "create identity provider" endpoints at least also had the option to automatically link to the organization login policy (the same way the delete endpoint automatically unlinks)
e.g. https://zitadel.com/docs/apis/resources/mgmt/management-service-add-generic-oidc-provider
ZITADEL Docs
Delete Identity Provider
ZITADEL Docs
Add Generic OIDC Identity Provider
@Rajat please let me know if that makes sense 😃
(I understand that I'm discussing the design of v1 endpoints that will probably be reworked on v2 api - but still I hope this discussion is useful to improve the general ergonomics of the API, particularly on those endpoints that haven't been released yet :zitadel: )
(I understand that I'm discussing the design of v1 endpoints that will probably be reworked on v2 api - but still I hope this discussion is useful to improve the general ergonomics of the API, particularly on those endpoints that haven't been released yet :zitadel: )
thanks for pointing it out, and as per my understanding, this was done by design 🙂
ZITADEL deliberately requires a two step process: one call to create the IDP provider, and a second to link (activate) it within the org login policy. The delete operation works in one step because it just removes the linked provider and deletes it.
ZITADEL deliberately requires a two step processRight, that's fair - and particularly from a permissions standpoint it makes a lot of sense Still though, I wish managing identity providers via API was a bit less cumbersome (from a developer experience standpoint) 😕 (not to mention having a different POST/PUT for each provider type... that's another developer experience hassle) Right now our backend application simply doesn't care much about the Zitadel's organizations' custom login policies (other than the linked idps), so it's a bit cumbersome having to explicitly manage it screenshots attached: * a section of a diagram we drafted internally related to how our application interacts with Zitadel for creating an organization's identity provider * all the related zitadel endpoints we're calling to be able to manage idps via API (considering we initially only support "oidc" and "azure ad" provider types)
Hope this feedback is taken into consideration for future Zitadel iterations - Zitadel is a fantastic piece of software and I'd love to see it thrive 😃
Still though, I wish managing identity providers via API was a bit less cumbersome (from a developer experience standpoint) 😕 (not to mention having a different POST/PUT for each provider type... that's another developer experience hassle) Right now our backend application simply doesn't care much about the Zitadel's organizations' custom login policies (other than the linked idps), so it's a bit cumbersome having to explicitly manage itthis could be fixed by actions v2 imo, you can set an execution to change login policies when an IDP is added