Keycloak jira issue for autoUpdated Identity Provider metadata from URL exists for long time. Our time is one of many teams that wants to use this feature.

We did an implementation described in the above jira issue based on @hmlnarik comment in previous jira issue :

What would be needed is the following: Store with the clients in the attributes: What IdP (if any) it comes from; Whether metadata refresh is enabled flag

• Store with the identity provider: Metadata URL, Last refresh time, Refresh period; Whether to delete clients which are not found in metadata flag; Whether to add clients that are found in the metadata and do not exist
• Scheduler that would periodically find identity providers that are past refresh time, then find those clients that should be updated and update those
• Support for SAML and OIDC metadata format

Our implementation has the logic to automatically update SAML/OIDC IdP on cache and DB/map. The same logic as a realm admin user updates IdP periodically.

@stianst comment in PR :

From a quick glance at this it seems that the background task will update the configuration in the DB? We should not do that, but rather instead only have the config URL stored in the DB. This is especially important in the future when we have support for static configuration where the identity provider is configured in a read-only YAML file.

To make it clear I'm certainly not advocating that it is parsed on every request, etc. rather that there is a local cache, or a cluster-wide cache that is updated, rather than updating the persisted/DB config.

Although I think that updating a cluster-wide cache would be a great solution, I do not know how to implement it and I need Keycloak team help. We must take into account that cache is per Realm , we will have also not autoUpdated IdPs and not all IdP fields are parsed from XML/json.
Do you have in mind that for autoUpdated IdP only cache will be take into account? How will autoUpdate task will be executed? What will happen at IdP creation/ Keycloak start up?

@stianst, @hmlnarik we could start a discussion in order to find a way to implement this useful task.