apicurio integration as kiota search provider

[baywet]

@andreaTP continuing the discussion here to avoid side-tracking the PR.
Original comment here

To answer some of your questions:

• Kiota's focus is on REST APIs and OpenAPI for the time being, there is a wealth of tooling available to convert other standards like CSDL or CADL to OpenAPI and we want to keep kiota focused.
• A first stopgap could be to add only support the hosted instance for now, and later support private instances. The main issue here being to authenticate reliably.

Do you have an OpenAPI description at hand for apicurio? I'm especially interested in things like:

• APIs to search API descriptions based on a set of keywords.
• APIs to download API descriptions based on their search entry.
• details about authentication

[andreaTP]

Thanks for opening this discussion!
This is the full OpenAPI description of a Registry instance, please note that in a multi-tenant setup, you would need to dynamically provision the instances using this API.

Authentication is usually done using Keycloak, but, to have access to the user's instances we would need to use or create a special client to be used; @carlesarnal will be able to elaborate further on this subject.

A first stopgap could be to add only support the hosted instance for now, and later support private instances.

Would it be possible to integrate using a push mechanism?
Also, do you implement any kind of multitenancy in the Search?

[baywet]

Thanks for the additional details here. Kiota is only reading at this point from any source. That means it wouldn't be creating instances or pushing descriptions, at least in the first set of changes.
As per multi-tenancy support, the only thing that's close to that today in the search experience is GitHub. And the federation of organizations/tenants is handled by GitHub's APIs for us as long as users configure their token/SSO properly at sign-in (which has proven to be a challenge).

[carlesarnal]

Hi all, sorry for the late reply.

First of all, I'm basing my answer on the hosted instance since @baywet said (and I agree) that this should be the first attempt. Given a situation where a user wants to be able to search artifacts (or Registry objects) from Kiota across the hosted instance, I think there are a couple of scenarios here, one integrated with our control plane (more complex) and one that is not (simpler):

• Integrated with the control plane. I think this should be the mid/long-term goal. With this integration, Kiota would need to acquire the access token by using a client credentials grant flow against the authentication server. These credentials must be configured beforehand and can then be used to scan our control plane for accessible Registry instances where the final artifacts/objects live. If a client credentials grant is already supported using Kiota it may be relatively straightforward to implement this part, if not, we have the second option as a fallback. This would allow the user to search across the set of instances that the mentioned set of credentials has access. This first scenario implies integrating not only the Registry API but also the srs-fleet-manager api that Andrea mentioned (or at minimum a part of it).

• No integration with control plane. Even more straightforward, the user is limited to search across only and only one Registry instance, the one configured to be used with Kiota. For this to work, all that is needed is to pass a pair of username/password as basic authentication when any request is sent to Registry. As I said, although this should be even more straightforward than the other solution mentioned, this one would be extremely limited.

Hope this makes sense, if not, please, ask any questions!

[andreaTP]

Thanks for following up @carlesarnal !

A couple of questions regarding the second option: No integration with control plane.

People will need to pass(somehow) to Kiota Search the URL of the Registry instance which is going to be a URL like: https://bu94.serviceregistry.rhcloud.com/t/96c84fa7-35d7-46e8-ad7a-8741a4463969/apis/registry/v2, is it correct?

Also, how do you envision the process of passing usernames and passwords to Kiota?

[baywet]

Thank for the additional details here. Our security and compliance team probably won't allow us to ship a solution that handles usernames and passwords, and for good reasons.

As per the integrated approach, which authentication flows are supported by the authentication provider? Ideally it'd support a device authorization grant for the native console experience, as well as the implicit flow or PKCE flow the web experience.