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. B
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
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
Hi Rushmin,
On Fri, Jan 24, 2020 at 5:37 PM Rushmin Fernando wrote:
>
>
> On Mon, Jan 20, 2020 at 12:29 PM Amila De Silva 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 A
On Mon, Jan 20, 2020 at 12:29 PM Amila De Silva 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 discuss
On Mon, Jan 20, 2020 at 4:51 PM Harsha Kumara wrote:
>
>
> On Mon, Jan 20, 2020 at 12:20 PM Amila De Silva 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
On Mon, Jan 20, 2020 at 12:20 PM Amila De Silva 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
On Mon, Jan 20, 2020 at 2:13 PM Dushani Wellappili
wrote:
> Hi Sanjeewa/Amila,
>
> +1 for adding permissions to view/manage the global scopes, so that only
> privileged users (admins) can create/update scopes. The reason to move the
> global scope management view to the Publisher portal is to all
Hi Sanjeewa/Amila,
+1 for adding permissions to view/manage the global scopes, so that only
privileged users (admins) can create/update scopes. The reason to move the
global scope management view to the Publisher portal is to allow API
developers to check what are the scopes available and view the
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 introductio
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 (
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 abo
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_SCO
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 wi
The delete operation should be corrected as follows.
#-
# Delete the global scope
#-
delete:
security:
- OAuth2Security:
- apim:global_scope_manage
summa
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
16 matches
Mail list logo
