Hi Ishara, We will not allow deleting global scopes if they are attached to any resource. Btw, Global scopes cannot be used across tenants, global scopes can be defined locally to a tenant. When a global scope is updated (role binding updates), we will provide a warning about the need to republish the APIs. Because role binding updates will not immediately reflect in the swagger unless we republish. Basic auth will not work properly in such cases.
*Dushani Wellappili* Senior Software Engineer - WSO2 Email : dusha...@wso2.com Mobile : +94779367571 Web : https://wso2.com/ On Wed, Feb 5, 2020 at 5:31 AM Ishara Cooray <isha...@wso2.com> wrote: > Hi Dushani, > > If a global scope is modified or deleted it will affect all the APIs that > it is being used. > How do we handle this? > There should be a way to identify the APIs that the scope is > associated with. > And when deleting we need to make sure that none of the APIs using the > scope. When modifying we need to at least warn about the usages of the > scope. > Also, it will introduce complexities when it comes to tenants. > > IMO we should not allow modifying/deleting global scopes because we can > easily create a new scope to match the requirements. > > Thanks & Regards, > Ishara Cooray > Associate Technical Lead > Mobile : +9477 262 9512 > WSO2, Inc. | http://wso2.com/ > Lean . Enterprise . Middleware > > > On Mon, Jan 27, 2020 at 12:04 PM Dushani Wellappili <dusha...@wso2.com> > wrote: > >> Hi Rushmin, >> >> >> On Fri, Jan 24, 2020 at 5:37 PM Rushmin Fernando <rush...@wso2.com> >> wrote: >> >>> >>> >>> On Mon, Jan 20, 2020 at 12:29 PM Amila De Silva <ami...@wso2.com> wrote: >>> >>>> A couple of other points needing the opinion of a wider audience are; >>>> >>>> 1. Whether only to support Global scopes in future releases and convert >>>> all per API scopes to Global scopes. >>>> >>>> One of the points raised during an internal discussion was that, per >>>> API scopes will get obsolete with the introduction of Global scopes, since >>>> a global scope can be used in the place of a per API scope. If an API >>>> Provider needs to use a completely different scope (than the ones already >>>> available in the system), they can still define it as a Global scope and >>>> assign it to the API/resource. The new scope will be a shared one and can >>>> be used for other APIs by different API developers. >>>> Unless an API Developer needs to restrict the usage of several scopes >>>> to a few selected APIs, Global scopes can replace per API scopes. >>>> >>>> >>> I believe that the UX of an API publisher gets affected due to the >>> following reasons if we allow only global scopes and not facilitate them >>> properly. >>> >>> - Two scopes might have the same name but might have two different >>> semantics in the context of two APIs. >>> >> >> Even with the current behavior (with local scopes), we do not provide the >> capability to have the same name for scopes of two different APIs. >> Irrespective of whether its a local or global scope, we will not allow >> having duplicate scope keys/names. >> >> >>> - There might be scopes which are semantically same but have different >>> names. >>> >> This is a case where we cannot control. IMO, it is a design choice of the >> privileged user/admin to create different scopes with same role bindings >> and use them across multiple APIs. >> >>> >>> So this might create confusion when choosing the scopes for an API >>> unless this is well-governed. >>> >>> >>> >>>> 2. While creating an API using the Swagger, only doing the scope >>>> assignments without creating any new scope. >>>> >>>> Suggestion is to use scopes defined in the swagger only to do scope to >>>> resource assignment. If the scopes are already available in the System, >>>> those will be assigned to the Resources as specified by the Swagger. If >>>> not, the API will be created without creating any scopes. This would help >>>> removing scope to role mapping from swagger and would also eliminate the >>>> need of identifying Global and Per-API scopes differently. But a different >>>> configuration is needed to keep that information while exporting/importing >>>> APIs. The idea is to have a clean Swagger while moving all wso2 specific >>>> configurations to a different file. >>>> >>>> >>>> On Mon, Jan 20, 2020 at 11:50 AM Dushani Wellappili <dusha...@wso2.com> >>>> wrote: >>>> >>>>> Hi all, >>>>> >>>>> According to the recent discussions we've had, we have modified the >>>>> initial DB design as follows. >>>>> >>>>> - Remove the FK constraint on SCOPE_ID, as it would be easy when >>>>> decoupling API-M from IS components in the future. >>>>> - Add a UUID for Global Scopes to support REST APIs >>>>> >>>>> AM_GLOBAL_SCOPE >>>>> SCOPE_ID INTEGER NOT NULL, >>>>> TENANT_ID INTEGER DEFAULT -1, >>>>> UUID VARCHAR (256) >>>>> >>>>> In addition, the following points are highlighted which we need to >>>>> discuss further. >>>>> >>>>> - The management of scopes can be done in the Publisher Portal and >>>>> it would make more sense if move it to the same UI view of APIs as >>>>> scopes >>>>> are straightly attached to APIs. >>>>> - With the above design of global scopes, there will be no way to >>>>> differentiate global and local scopes from the swagger. Hence, if the >>>>> global scope - role bindings are updated after publishing the API, the >>>>> role >>>>> changes will not be reflected when validating API requests using Basic >>>>> Auth. In such cases, we need to republish the APIs. >>>>> - Currently, we do not support adding local scopes with the same >>>>> name for different APIs. Hence, other than using local scopes to >>>>> restrict >>>>> the use of the same for other APIs, there would not be any difference >>>>> between local and global scopes. >>>>> - If we are removing local scope support, we need to migrate the >>>>> existing local scopes of previous versions to global. In migration, we >>>>> need >>>>> to add the existing scope_ids and tenant_ids to the AM_GLOBAL_SCOPE >>>>> table >>>>> with new UUIDs. >>>>> >>>>> >>>>> Thanks >>>>> >>>>> *Dushani Wellappili* >>>>> Senior Software Engineer - WSO2 >>>>> >>>>> Email : dusha...@wso2.com >>>>> Mobile : +94779367571 >>>>> Web : https://wso2.com/ >>>>> >>>>> >>>>> >>>>> >>>>> On Mon, Jan 20, 2020 at 11:19 AM Dushani Wellappili <dusha...@wso2.com> >>>>> wrote: >>>>> >>>>>> Hi all, >>>>>> >>>>>> This is to provide an example use-case of supporting global scopes >>>>>> when an application is using multiple APIs and it supports >>>>>> functionalities >>>>>> for users with different types of permissions. There are two sets of >>>>>> users >>>>>> where the one set will only have view-only permissions and another set >>>>>> will >>>>>> have both read and edit permissions. >>>>>> >>>>>> For example, assume an application is using both API A and B. API A >>>>>> has 2 operations ( /a GET, /a POST) and similarly API B has 2 operations >>>>>> ( >>>>>> /b GET, /b POST). The users of set 1 only have read permission and set 2 >>>>>> have both read-write permissions. The permissions are given by assigning >>>>>> roles. >>>>>> >>>>>> set 1 user - role 1 (read-only role) >>>>>> set 2 users - role 2 (read-write role) >>>>>> >>>>>> The users of set 1 need to be provided access for both (/a GET) and >>>>>> (/b GET). The users of set 2 need to be provided access for all the 4 >>>>>> operations (/a GET, /a POST, /b GET, /b POST) of API A and API B. >>>>>> >>>>>> With the current functionality of WSO2 API-M local scopes, this can >>>>>> be achieved by creating 2 local scopes (view-scope, edit-scope) for >>>>>> each API, and define role bindings of the users based on the permissions >>>>>> they have. Then, assign them to the API operations. >>>>>> >>>>>> *API A* >>>>>> view-scopeA - role1, role2 >>>>>> edit-scopeA - role2 >>>>>> >>>>>> /a GET view-scopeA >>>>>> /a POST edit-scopeA >>>>>> >>>>>> *API B* >>>>>> view-scopeB - role1, role2 >>>>>> edit-scopeB - role2 >>>>>> >>>>>> /b GET view-scopeB >>>>>> /b POST edit-scopeB >>>>>> >>>>>> The main limitation of the above way is that we need to create 4 >>>>>> scopes separately with 4 unique scope keys duplicating the scope-role >>>>>> bindings. Hence, for such cases, it is ideal to have the capability to >>>>>> define the scope-role bindings globally and reuse them in the API >>>>>> operations. So the API developers can restrict access for the API >>>>>> operations of the APIs globally. >>>>>> >>>>>> So there will be only two scopes which needs to be created globally. >>>>>> view-scope - role1, role2 >>>>>> edit-scope - role2 >>>>>> >>>>>> *API A* >>>>>> /a GET view-scope >>>>>> /a POST edit-scope >>>>>> >>>>>> *API B* >>>>>> /b GET view-scope >>>>>> /b POST edit-scope >>>>>> >>>>>> In addition to the above, if there will be later requirement where >>>>>> there is another set of users with a different set of permissions (role3) >>>>>> and they need to be given permission to use (/b GET) operation of API B. >>>>>> If >>>>>> so, with the above design where we do not support multiple scopes per >>>>>> resource, we need to create another new scope with all role1, role2, >>>>>> and role3 bindings. Then assign it for (/b GET) instead of edit-scope. In >>>>>> that case, the point of reusing global scopes across multiple APIs would >>>>>> not become beneficial. Hence, by supporting multiple scopes per resource, >>>>>> we can keep the above design as it is and separately create a >>>>>> global/local >>>>>> scope with bindings for role3 and attach it to (/b GET) operation. >>>>>> >>>>>> new-scope - role3 >>>>>> >>>>>> *API B* >>>>>> /b GET view-scope, new-scope >>>>>> /b POST edit-scope >>>>>> >>>>>> >>>>>> >>>>>> *Dushani Wellappili* >>>>>> Senior Software Engineer - WSO2 >>>>>> >>>>>> Email : dusha...@wso2.com >>>>>> Mobile : +94779367571 >>>>>> Web : https://wso2.com/ >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> On Thu, Jan 16, 2020 at 10:18 PM Dushani Wellappili < >>>>>> dusha...@wso2.com> wrote: >>>>>> >>>>>>> The delete operation should be corrected as follows. >>>>>>> >>>>>>> #----------------------------------------------------- >>>>>>> >>>>>>> # Delete the global scope >>>>>>> >>>>>>> #----------------------------------------------------- >>>>>>> >>>>>>> delete: >>>>>>> >>>>>>> security: >>>>>>> >>>>>>> - OAuth2Security: >>>>>>> >>>>>>> - apim:global_scope_manage >>>>>>> >>>>>>> summary: Delete a global scope >>>>>>> >>>>>>> description: | >>>>>>> >>>>>>> This operation can be used to delete an existing Global >>>>>>> Scope proving the Id of the scope. >>>>>>> >>>>>>> parameters: >>>>>>> >>>>>>> - $ref: '#/parameters/scopeId >>>>>>> >>>>>>> responses: >>>>>>> >>>>>>> 200: >>>>>>> >>>>>>> description: | >>>>>>> >>>>>>> OK. >>>>>>> >>>>>>> Resource successfully deleted. >>>>>>> >>>>>>> 404: >>>>>>> >>>>>>> description: | >>>>>>> >>>>>>> Not Found. >>>>>>> >>>>>>> The resource to be deleted does not exist. >>>>>>> >>>>>>> schema: >>>>>>> >>>>>>> $ref: '#/definitions/Error' >>>>>>> >>>>>>> >>>>>>> >>>>>>> *Dushani Wellappili* >>>>>>> Senior Software Engineer - WSO2 >>>>>>> >>>>>>> Email : dusha...@wso2.com >>>>>>> Mobile : +94779367571 >>>>>>> Web : https://wso2.com/ >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> On Thu, Jan 16, 2020 at 3:33 PM Dushani Wellappili < >>>>>>> dusha...@wso2.com> wrote: >>>>>>> >>>>>>>> Hi all, >>>>>>>> >>>>>>>> - Global OAuth2 Scopes are useful when an >>>>>>>> organization/department (a tenant) has a need to globally control >>>>>>>> the fined >>>>>>>> grained access control permissions of all the published APIs, from a >>>>>>>> central place. >>>>>>>> - It reduces the rework of creating the same scope with >>>>>>>> duplicate access control permissions for each of the API. With >>>>>>>> this, such >>>>>>>> scope creation would be a one time task. Global scopes will be >>>>>>>> created by >>>>>>>> administrative users and the API developers can attach the >>>>>>>> available global >>>>>>>> scopes for the API resources when designing the API. >>>>>>>> - The support to add multiple OAuth scopes per resource is >>>>>>>> useful when you need to group the access permissions to resources >>>>>>>> by scopes >>>>>>>> and reuse them across different APIs. >>>>>>>> >>>>>>>> *DESIGN* >>>>>>>> >>>>>>>> - The global scope management view will be added to the >>>>>>>> Publisher UI so that the API developers can easily check what are >>>>>>>> the >>>>>>>> available global scopes and their role bindings from the same >>>>>>>> portal when >>>>>>>> creating an API. >>>>>>>> - Current Publisher Portal UI for Resource Management of an API >>>>>>>> will be modified to attach the global scopes and attach multiple >>>>>>>> scopes per >>>>>>>> resource. >>>>>>>> - The current flow of managing and attaching per API scopes >>>>>>>> will remain as it is. >>>>>>>> - To make sure that only privileged users(admins) can >>>>>>>> add/update/delete any global scope, the relevant Publisher REST >>>>>>>> APIs will >>>>>>>> be secured using a REST API scope. Eg: apim:global_scope_manage >>>>>>>> - To support global scopes, we need to add a new table >>>>>>>> AM_GLOBAL_SCOPE on AM_DB. >>>>>>>> >>>>>>>> *AM_GLOBAL_SCOPE* >>>>>>>> SCOPE_ID INTEGER NOT NULL, >>>>>>>> TENANT_ID INTEGER DEFAULT -1, >>>>>>>> FOREIGN KEY (SCOPE_ID) REFERENCES IDN_OAUTH2_SCOPE (SCOPE_ID) >>>>>>>> ON DELETE CASCADE >>>>>>>> >>>>>>>> >>>>>>>> - We need to modify the PK constraint on >>>>>>>> IDN_OAUTH2_RESOURCE_SCOPE to be a composite key on both >>>>>>>> RESOURCE_PATH and SCOPE_ID to support multiple scopes per resource. >>>>>>>> >>>>>>>> >>>>>>>> *IDN_OAUTH2_RESOURCE_SCOPE * >>>>>>>> RESOURCE_PATH VARCHAR(255) NOT NULL, >>>>>>>> SCOPE_ID INTEGER NOT NULL, >>>>>>>> TENANT_ID INTEGER DEFAULT -1, >>>>>>>> PRIMARY KEY (SCOPE_ID, RESOURCE_PATH), >>>>>>>> FOREIGN KEY (SCOPE_ID) REFERENCES IDN_OAUTH2_SCOPE >>>>>>>> (SCOPE_ID) ON DELETE CASCADE >>>>>>>> >>>>>>>> >>>>>>>> - JDBCScopeValidator will be modified to support validating >>>>>>>> multiple scopes attached per resource. >>>>>>>> - Global Scopes will be added via the following Publisher REST >>>>>>>> APIs. Using resource name "global-scopes" seems more appropriate >>>>>>>> since >>>>>>>> these REST APIs will be used to only manage global scopes. The >>>>>>>> "Scope" >>>>>>>> resource and "ScopeList" resource are already defined in Publisher >>>>>>>> REST >>>>>>>> API, hence we can use the same resources for global-scopes as well. >>>>>>>> >>>>>>>> >>>>>>>> ###################################################### >>>>>>>> >>>>>>>> # The "Global Scopes" resource APIs >>>>>>>> >>>>>>>> ###################################################### >>>>>>>> >>>>>>>> /global-scopes >>>>>>>> >>>>>>>> >>>>>>>> #------------------------------------------------------------- >>>>>>>> >>>>>>>> # Retrieve the global scopes list >>>>>>>> >>>>>>>> #------------------------------------------------------------- >>>>>>>> >>>>>>>> get: >>>>>>>> >>>>>>>> security: >>>>>>>> >>>>>>>> - OAuth2Security: >>>>>>>> >>>>>>>> - apim:api_view >>>>>>>> >>>>>>>> summary: Get the list of global scopes >>>>>>>> >>>>>>>> responses: >>>>>>>> >>>>>>>> 200: >>>>>>>> >>>>>>>> description: | >>>>>>>> >>>>>>>> OK. >>>>>>>> >>>>>>>> Global Scope list is returned. >>>>>>>> >>>>>>>> schema: >>>>>>>> >>>>>>>> $ref: '#/definitions/ScopeList' >>>>>>>> >>>>>>>> headers: >>>>>>>> >>>>>>>> Content-Type: >>>>>>>> >>>>>>>> description: | >>>>>>>> >>>>>>>> The content type of the body. >>>>>>>> >>>>>>>> type: string >>>>>>>> >>>>>>>> 500: >>>>>>>> >>>>>>>> description: Internal server error while retrieving >>>>>>>> global scope list >>>>>>>> >>>>>>>> schema: >>>>>>>> >>>>>>>> $ref: '#/definitions/Error' >>>>>>>> >>>>>>>> >>>>>>>> #------------------------------------------------------------- >>>>>>>> >>>>>>>> # Create a new global scope >>>>>>>> >>>>>>>> #------------------------------------------------------------- >>>>>>>> >>>>>>>> post: >>>>>>>> security: >>>>>>>> - OAuth2Security: >>>>>>>> - apim:global_scope_manage >>>>>>>> summary: Add a new global scope >>>>>>>> description: | >>>>>>>> This operation can be used to add a new global scope. >>>>>>>> parameters: >>>>>>>> - in: body >>>>>>>> name: body >>>>>>>> description: | >>>>>>>> Scope object that needs to be added >>>>>>>> required: true >>>>>>>> schema: >>>>>>>> $ref: '#/definitions/Scope' >>>>>>>> responses: >>>>>>>> 201: >>>>>>>> description: | >>>>>>>> Created. >>>>>>>> Successful response with the newly created Scope object >>>>>>>> as an entity in the body. >>>>>>>> schema: >>>>>>>> $ref: '#/definitions/Scope' >>>>>>>> headers: >>>>>>>> Content-Type: >>>>>>>> description: | >>>>>>>> The content type of the body. >>>>>>>> type: string >>>>>>>> 400: >>>>>>>> description: | >>>>>>>> Bad Request. >>>>>>>> Invalid request or validation error >>>>>>>> schema: >>>>>>>> $ref: '#/definitions/Error' >>>>>>>> 415: >>>>>>>> description: | >>>>>>>> Unsupported media type. >>>>>>>> The entity of the request was in a not supported format. >>>>>>>> >>>>>>>> >>>>>>>> ###################################################### >>>>>>>> >>>>>>>> # The "Individual Global Scope" resource APIs >>>>>>>> >>>>>>>> ###################################################### >>>>>>>> >>>>>>>> /global-scopes/{scopeId} >>>>>>>> >>>>>>>> >>>>>>>> #------------------------------------------------------------- >>>>>>>> >>>>>>>> # Retrieve the details of a global scope >>>>>>>> >>>>>>>> #------------------------------------------------------------- >>>>>>>> >>>>>>>> >>>>>>>> get: >>>>>>>> >>>>>>>> security: >>>>>>>> >>>>>>>> - OAuth2Security: >>>>>>>> >>>>>>>> - apim:api_view >>>>>>>> >>>>>>>> summary: Get details of a global scope >>>>>>>> >>>>>>>> parameters: >>>>>>>> - $ref: '#/parameters/scopeId' >>>>>>>> >>>>>>>> responses: >>>>>>>> >>>>>>>> 200: >>>>>>>> >>>>>>>> description: | >>>>>>>> >>>>>>>> OK. >>>>>>>> >>>>>>>> Requested Global Scope is returned. >>>>>>>> >>>>>>>> schema: >>>>>>>> >>>>>>>> $ref: '#/definitions/Scope' >>>>>>>> >>>>>>>> headers: >>>>>>>> >>>>>>>> Content-Type: >>>>>>>> >>>>>>>> description: | >>>>>>>> >>>>>>>> The content type of the body. >>>>>>>> >>>>>>>> type: string >>>>>>>> >>>>>>>> 404: >>>>>>>> description: | >>>>>>>> Not Found. >>>>>>>> Requested Global Scope does not exist. >>>>>>>> schema: >>>>>>>> $ref: '#/definitions/Error' >>>>>>>> >>>>>>>> >>>>>>>> #------------------------------------------------------------- >>>>>>>> >>>>>>>> # Update a global scope >>>>>>>> >>>>>>>> #------------------------------------------------------------- >>>>>>>> >>>>>>>> put: >>>>>>>> >>>>>>>> security: >>>>>>>> >>>>>>>> - OAuth2Security: >>>>>>>> >>>>>>>> - apim:global_scope_manage >>>>>>>> >>>>>>>> summary: Update an API >>>>>>>> >>>>>>>> description: | >>>>>>>> >>>>>>>> This operation can be used to update an existing Global >>>>>>>> Scope. >>>>>>>> >>>>>>>> parameters: >>>>>>>> >>>>>>>> - $ref: '#/parameters/scopeId' >>>>>>>> >>>>>>>> - in: body >>>>>>>> >>>>>>>> name: body >>>>>>>> >>>>>>>> description: | >>>>>>>> >>>>>>>> Scope object that needs to be updated >>>>>>>> >>>>>>>> required: true >>>>>>>> >>>>>>>> schema: >>>>>>>> >>>>>>>> $ref: '#/definitions/Scope' >>>>>>>> >>>>>>>> responses: >>>>>>>> >>>>>>>> 200: >>>>>>>> >>>>>>>> description: | >>>>>>>> >>>>>>>> OK. >>>>>>>> >>>>>>>> Successful response with updated Scope object >>>>>>>> >>>>>>>> schema: >>>>>>>> >>>>>>>> $ref: '#/definitions/Scope' >>>>>>>> >>>>>>>> headers: >>>>>>>> >>>>>>>> Content-Type: >>>>>>>> >>>>>>>> description: | >>>>>>>> >>>>>>>> The content type of the body. >>>>>>>> >>>>>>>> type: string >>>>>>>> >>>>>>>> 400: >>>>>>>> >>>>>>>> description: | >>>>>>>> >>>>>>>> Bad Request. >>>>>>>> >>>>>>>> Invalid request or validation error >>>>>>>> >>>>>>>> schema: >>>>>>>> >>>>>>>> $ref: '#/definitions/Error' >>>>>>>> >>>>>>>> 404: >>>>>>>> >>>>>>>> description: | >>>>>>>> >>>>>>>> Not Found. >>>>>>>> >>>>>>>> The resource to be updated does not exist. >>>>>>>> >>>>>>>> schema: >>>>>>>> >>>>>>>> $ref: '#/definitions/Error' >>>>>>>> >>>>>>>> >>>>>>>> #----------------------------------------------------- >>>>>>>> >>>>>>>> # Delete the definition of an API >>>>>>>> >>>>>>>> #----------------------------------------------------- >>>>>>>> >>>>>>>> delete: >>>>>>>> >>>>>>>> security: >>>>>>>> >>>>>>>> - OAuth2Security: >>>>>>>> >>>>>>>> - apim:global_scope_manage >>>>>>>> >>>>>>>> summary: Delete an API >>>>>>>> >>>>>>>> description: | >>>>>>>> >>>>>>>> This operation can be used to delete an existing Global >>>>>>>> Scope proving the Id of the scope. >>>>>>>> >>>>>>>> parameters: >>>>>>>> >>>>>>>> - $ref: '#/parameters/scopeId >>>>>>>> >>>>>>>> responses: >>>>>>>> >>>>>>>> 200: >>>>>>>> >>>>>>>> description: | >>>>>>>> >>>>>>>> OK. >>>>>>>> >>>>>>>> Resource successfully deleted. >>>>>>>> >>>>>>>> 404: >>>>>>>> >>>>>>>> description: | >>>>>>>> >>>>>>>> Not Found. >>>>>>>> >>>>>>>> Resource to be deleted does not exist. >>>>>>>> >>>>>>>> schema: >>>>>>>> >>>>>>>> $ref: '#/definitions/Error' >>>>>>>> >>>>>>>> *FLOW* >>>>>>>> >>>>>>>> 1. A privileged user/administrative user logs into Publisher Portal >>>>>>>> and creates a global scope providing name, description and role >>>>>>>> bindings. >>>>>>>> 2. Upon checking whether the scope key is not duplicated in the >>>>>>>> IDN_OAUTH2_SCOPE table, this scope will be added to the >>>>>>>> IDN_OAUTH2_SCOPE, >>>>>>>> IDN_OAUTH2_SCOPE2_BINDING and AM_GLOBAL_SCOPE tables. >>>>>>>> 3. An API developer creates an API and visits the resources page. >>>>>>>> The list of scopes to add per resource is populated using the per-API >>>>>>>> scopes from the API object and from the "GET /global-scopes" backend >>>>>>>> service call. >>>>>>>> 4. The developer selects a set of global/per-API scopes for the >>>>>>>> resource. The swagger is updated with the scopes list and resource >>>>>>>> scope >>>>>>>> list. The backend service "PUT apis/{apiId}/swagger" updates the >>>>>>>> IDN_OAUTH2_RESOURCE_SCOPE and AM_API_SCOPES table. >>>>>>>> 5. App Developer will generate a token with the scopes and invoke >>>>>>>> the API. During the KeyValidation service, when the scopes are >>>>>>>> validated >>>>>>>> for the resource using the JDBCScopeValidator, it will check whether >>>>>>>> token >>>>>>>> bears any of the given resource scopes. >>>>>>>> >>>>>>>> This is a draft design for the implementation. Hence appreciate >>>>>>>> your suggestions/comments to improve the above. Once the above is >>>>>>>> finalized, we will work on the UI design. >>>>>>>> >>>>>>>> Thanks >>>>>>>> >>>>>>>> *Dushani Wellappili* >>>>>>>> Senior Software Engineer - WSO2 >>>>>>>> >>>>>>>> Email : dusha...@wso2.com >>>>>>>> Mobile : +94779367571 >>>>>>>> Web : https://wso2.com/ >>>>>>>> >>>>>>>> >>>>>>>> >>>> >>>> -- >>>> *Amila De Silva* >>>> Software Architect | Associate Director, Engineering - WSO2 Inc. >>>> (m) +94 775119302 | (e) ami...@wso2.com >>>> <http://wso2.com/signature> >>>> _______________________________________________ >>>> Architecture mailing list >>>> Architecture@wso2.org >>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>>> >>> >>> >>> -- >>> *Rushmin Fernando* >>> *Technical Lead* >>> >>> WSO2 Inc. <http://wso2.com/> - Lean . Enterprise . Middleware >>> >>> mobile : +94775615183 >>> >>> >>> >>> _______________________________________________ >>> Architecture mailing list >>> Architecture@wso2.org >>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>> >> _______________________________________________ >> Architecture mailing list >> Architecture@wso2.org >> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >> >
_______________________________________________ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
