This is regarding the issue <https://github.com/wso2/product-apim-tooling/issues/128> which raises when the API Controller (apictl) tries to import an open API created by using an external API swagger definition.
This issue expanded to the API Manager as well, because when creating an API using the API Publisher portal using a swagger definition with security scopes, those are not getting assigned to the resources sometimes. Currently, the API publisher does not support multiple OAuth2 scope schemes and support only 'default' scope schemes. But when a customer brings their own API definition as a swagger file there can be OAuth2 scope schemes that are not written in the 'default' scope scheme. In that case, currently, those scopes do not get exposed or used in API publisher to generate tokens or perform any other operations. Since Microgateway supports these types of different OAuth2 scope schemes the APIM product should provide support for this particular scenario. The discussion was carried out regarding this matter and a set of approaches was suggested during that discussion. Approaches 1. Implement multiple scope scheme support from the publisher UI. - In this approach what we are going to change the way that scopes are adding right now in the publisher. From the UI, there is a selection of what the OAuth2 scope scheme is to use when adding a scope. And that selection should be applied to the resources as well. Disadvantage - But this should be implemented from scratch which involves database changes, registry changes, and other security measures. Since APIM does not validate multiple grant types this approach can be troublesome. Advantage - On the other hand even though this approach is complex, it will provide a clear solution to the issue at hand. 1. Change the swagger file when importing into APIM publisher - In this approach what we are going to do is copy or replace the Oauth2 scope definitions that are not default scheme into default schemes. In this approach, the swagger definition can be replaced or merged with the changes. And that changed swagger definition will be the subject to OAS3 parser or OAS2 parser. Then the API exposing process will go on as in the current procedure. Disadvantage - In this approach since we make a change to the swagger file when the support of multiple scope schemes implemented properly this fix will be troublesome. Advantage - For the moment this approach will provide a fix to the use-case that we discussed above without breaking or interrupting the existing chain of processes. Eg: External Swagger Scheme The way resources use these security schemes originally. After the change. The way resources use these security schemes after the fix of the issue. [image: image.png] Your feedback on this issue and suggested approaches will be much appreciated. Furthermore, it would be great if new more simplified approaches can be identified in addition to the above-stated approaches. Thank you! -- *Chamindu Udakara* | Software Engineer | WSO2 Inc *mobile *: *+94 755285531 *| *email *: [email protected]
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
