+1 to the second approach as we need to implement this for 3.1.0 as a WUM and we need to do this with a least amount of changes as possible. Later I think we should look at how we can achieve the first approach as well.
Thanks On Fri, Apr 17, 2020 at 2:16 PM Chamindu Udakara <chami...@wso2.com> wrote: > 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 *: chami...@wso2.com > > -- Malintha Amarasinghe *WSO2, Inc. - lean | enterprise | middleware* http://wso2.com/ Mobile : +94 712383306
_______________________________________________ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
