On Mon, Jan 20, 2020 at 4:51 PM Harsha Kumara <[email protected]> wrote:
> > > On Mon, Jan 20, 2020 at 12:20 PM Amila De Silva <[email protected]> wrote: > >> Hi Sanjeewa, >> How about having a separate permission for creating/managing Scopes and >> assigning it to a selected few API Creators? If the Global scope creation >> becomes a simple process may be we can have it under Publisher UI or if it >> involves retaining some of the functionality Per-API-Scopes had (like being >> able to select a few APIs where a particular scope can be used with) then >> we can have a different UI under Admin portal. But regardless of where it >> resides, having a permission, would give some level of flexibility, with >> determining who can create/manage the scopes. >> > Yes I think the same and having this in publisher UI and control via scope > will be much more convenient. > +1 for having some sort of control over global scopes. > > @Dushani Wellappili <[email protected]> regarding the basic > authentication, I don't see any other option rather publishing the APIs. We > may provide a warning message. > IMO it will be slightly problematic as we need to identify almost all the APIs which are using this updated scopes. Publishing them automatically without knowing API creator/publisher will be a problem as it need redeployment. And i''m not sure if we allow API creators to keep API metadata changes without publishing(all published API changes done in publisher used to push gateway when we hit save button). If that is the case then it will be a problem again. May be notifying API creator/publisher about changes happened will be a good idea. Still direct publishing all affected APIs look simple. Let's think a little more and come to conclusion. > > It would be best to release global scope feature along with the current > scope behavior and depend on the usage we can decide whether we > discontinue the local scope feature. > I think current local scope feature will be there anyway. This will come on top of that. Thanks, sanjeewa. > >> >> On Mon, Jan 20, 2020 at 11:53 AM Sanjeewa Malalgoda <[email protected]> >> wrote: >> >>> Hi All, >>> Creating global scope is always admin task or should we let publishers >>> to initiate creating global scopes. Asking this because most of the time >>> its developers who create scopes and sometimes they may think this scope >>> can use widely. Isn't it a case we should consider. Also need to think >>> about scenarios related to basic auth as role assignment change for global >>> role does not reflect to API level metadata stored in gateway. >>> >>> Thanks, >>> sanjeewa. >>> >>> On Mon, Jan 20, 2020 at 11:50 AM Dushani Wellappili <[email protected]> >>> 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 : [email protected] >>>> Mobile : +94779367571 >>>> Web : https://wso2.com/ >>>> >>>> >>>> >>>> >>>> On Mon, Jan 20, 2020 at 11:19 AM Dushani Wellappili <[email protected]> >>>> 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 : [email protected] >>>>> Mobile : +94779367571 >>>>> Web : https://wso2.com/ >>>>> >>>>> >>>>> >>>>> >>>>> On Thu, Jan 16, 2020 at 10:18 PM Dushani Wellappili <[email protected]> >>>>> 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 : [email protected] >>>>>> Mobile : +94779367571 >>>>>> Web : https://wso2.com/ >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> On Thu, Jan 16, 2020 at 3:33 PM Dushani Wellappili <[email protected]> >>>>>> 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 : [email protected] >>>>>>> Mobile : +94779367571 >>>>>>> Web : https://wso2.com/ >>>>>>> >>>>>>> >>>>>>> >>> >>> -- >>> *Sanjeewa Malalgoda* >>> Software Architect | Associate Director, Engineering - WSO2 Inc. >>> (m) +94 712933253 | (e) [email protected] | (b) Blogger >>> <http://sanjeewamalalgoda.blogspot.com>, Medium >>> <https://medium.com/@sanjeewa190> >>> >>> GET INTEGRATION AGILE <https://wso2.com/signature> >>> Integration Agility for Digitally Driven Business >>> >> >> >> -- >> *Amila De Silva* >> Software Architect | Associate Director, Engineering - WSO2 Inc. >> (m) +94 775119302 | (e) [email protected] >> <http://wso2.com/signature> >> > > > -- > > *Harsha Kumara* > > Technical Lead, WSO2 Inc. > Mobile: +94775505618 > Email: [email protected] > Blog: harshcreationz.blogspot.com > > GET INTEGRATION AGILE > Integration Agility for Digitally Driven Business > -- *Sanjeewa Malalgoda* Software Architect | Associate Director, Engineering - WSO2 Inc. (m) +94 712933253 | (e) [email protected] | (b) Blogger <http://sanjeewamalalgoda.blogspot.com>, Medium <https://medium.com/@sanjeewa190> GET INTEGRATION AGILE <https://wso2.com/signature> Integration Agility for Digitally Driven Business
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
