[Dev] [Architecture] [APIM] [EMM] Adding multiple scopes to a single API resource endpoint

[Dilan Udara Ariyaratne]

Adding the thread to architecture, as this proposes an architectural change
to existing OAuth scopes @ APIM level.

Regards,
Dilan.

*Dilan U. Ariyaratne*
Senior Software Engineer
WSO2 Inc. 
Mobile: +94766405580 <%2B94766405580>
lean . enterprise . middleware


On Tue, Aug 9, 2016 at 6:30 AM, Dilan Udara Ariyaratne 
wrote:

> Hi Sam,
>
> I also think that Chathura is making a valid point here.
>
> For example, let's take the exact problem that EMM APIs do have currently.
>
> I am considering GET /devices API here. For this API, we do have a
> requirement to compile two responses
> based on the type of user accessing the API.
>
> [1] If he is simply a device owner, he would only get the details of his
> own devices.
> [2] If he is an admin user, he would get the facility of retrieving all
> the devices for that particular tenant.
>
> Since we can currently map only one scope with an API endpoint, that can
> only be useful in verifying whether the particular user is capable
> of accessing the API endpoint or not. This one-to-one level of API scoping
> is not enough in identifying to
> which of the above two responses, the user is authorized to access.
>
> If we had one-to-many level of API scoping, the story is different.
> Then we can add two scopes like, get-owning-devices and get-all-devices
> to the API, let a user access the API first by having either of two scopes.
> Next, we can simply decide what response to be authorized based on which
> of the two scopes, user is having.
>
> Since we do not currently have this facility of one-to-many level of API
> scoping, to achieve the same functionality, we have now
> got to think of other alternatives. Two such alternatives are:
>
> [1] Splitting the GET /devices API to two different APIs such that each
> would cater one of the above two responses
> and bring in the mentioned scopes to each of them separately:
>
> Although this is doable, this seems like duplicating
> the same business logic in multiple APIs again and again.
>
> [2] Introducing a predefined role such as get-all-devices and validate
> what response to be compiled based on that.
> If the user accessing the API has this role, in addition to the assigned
> API scope, he would get the facility of retrieving all the devices
> for that particular tenant or otherwise,only get the details of his own
> devices:
>
> Although this also seems doable, now we are simply in a process of
> complicating permission management side of our application.
> Since the capability of retrieving details of all devices is already
> provided by a predefined role, now we do not have the
> luxury of creating one single role having the same capability + another
> set of capabilities simply because of the fact that a role cannot be
> assigned to another role.
> With this limitation, as of now if an administrator wants to assign a user
> the capability of retrieving details of all devices + another set of
> capabilities,
> he cannot simply do that by assigning the user a single role, instead he
> would need to assign at least two roles. This could get even worse
> if we have the same issue for many other APIs as well. All this is because
> we are violating the fundamental principals
> and trying to authorize capabilities of our application directly via roles
> instead of scopes or permissions.
>
> Cheers,
> Dilan.
>
>
>
> *Dilan U. Ariyaratne*
> Senior Software Engineer
> WSO2 Inc. 
> Mobile: +94766405580 <%2B94766405580>
> lean . enterprise . middleware
>
>
> On Mon, Aug 8, 2016 at 2:08 PM, Chathura Dilan  wrote:
>
>> Hi Sam,
>>
>> Sometimes based on the scopes we might need to authorize the APIs to get
>> different responses.
>>
>> Eg: Facebook scopes [1]. At the login we can send multiple scopes,
>> generate the token and authorize an API based on scopes.
>>
>> It is not possible if only one scope is assigned to one API (resource).
>>
>> IMO scopes should be initially designed when the APIs are designed
>> regardless of the roles that they would be attached to.
>>
>> [1] - https://developers.facebook.com/docs/facebook-login/permissions
>>
>>
>>
>> On Thu, Aug 4, 2016 at 1:41 PM, Milan Perera  wrote:
>>
>>> Hi Sam,
>>>
>>> Thanks for the clarification.
>>>
>>> On Thu, Aug 4, 2016 at 12:34 PM, Sam Sivayogam  wrote:
>>>
 Hi Milan,

 In APIM scopes are there to give access controls based on user roles. A
 scope can contain multiple user roles so if you want to block multiple
 roles add those roles to a* single scope *and assign to the particular
 resource. IMO there is no need to create multiple scopes with different
 roles and assigning it to the same resource, when you can already create a
 scope with multiple roles.

 Thanks,
 Sam

 On Thu, Aug 4, 2016 at 12:25 PM, Milan Perera  wrote:

> Hi all,
>
> While going through the code I found that URITemplate class has an
> attribute to store multiple scopes.
>
> pack

Re: [Dev] [Architecture] [APIM] [EMM] Adding multiple scopes to a single API resource endpoint

[Nuwan Dias]

Whose responsibility is it to decide what details to return in the response
based on the user who's requesting it? Is it the fronting API's
responsibility to decide this or should it be the core back-end of the
Application who should be deciding who gets what?

On Tue, Aug 9, 2016 at 6:47 AM, Dilan Udara Ariyaratne 
wrote:

> Adding the thread to architecture, as this proposes an architectural
> change to existing OAuth scopes @ APIM level.
>
> Regards,
> Dilan.
>
> *Dilan U. Ariyaratne*
> Senior Software Engineer
> WSO2 Inc. 
> Mobile: +94766405580 <%2B94766405580>
> lean . enterprise . middleware
>
>
> On Tue, Aug 9, 2016 at 6:30 AM, Dilan Udara Ariyaratne 
> wrote:
>
>> Hi Sam,
>>
>> I also think that Chathura is making a valid point here.
>>
>> For example, let's take the exact problem that EMM APIs do have currently.
>>
>> I am considering GET /devices API here. For this API, we do have a
>> requirement to compile two responses
>> based on the type of user accessing the API.
>>
>> [1] If he is simply a device owner, he would only get the details of his
>> own devices.
>> [2] If he is an admin user, he would get the facility of retrieving all
>> the devices for that particular tenant.
>>
>> Since we can currently map only one scope with an API endpoint, that can
>> only be useful in verifying whether the particular user is capable
>> of accessing the API endpoint or not. This one-to-one level of API
>> scoping is not enough in identifying to
>> which of the above two responses, the user is authorized to access.
>>
>> If we had one-to-many level of API scoping, the story is different.
>> Then we can add two scopes like, get-owning-devices and get-all-devices
>> to the API, let a user access the API first by having either of two scopes.
>> Next, we can simply decide what response to be authorized based on which
>> of the two scopes, user is having.
>>
>> Since we do not currently have this facility of one-to-many level of API
>> scoping, to achieve the same functionality, we have now
>> got to think of other alternatives. Two such alternatives are:
>>
>> [1] Splitting the GET /devices API to two different APIs such that each
>> would cater one of the above two responses
>> and bring in the mentioned scopes to each of them separately:
>>
>> Although this is doable, this seems like duplicating
>> the same business logic in multiple APIs again and again.
>>
>> [2] Introducing a predefined role such as get-all-devices and validate
>> what response to be compiled based on that.
>> If the user accessing the API has this role, in addition to the assigned
>> API scope, he would get the facility of retrieving all the devices
>> for that particular tenant or otherwise,only get the details of his own
>> devices:
>>
>> Although this also seems doable, now we are simply in a process of
>> complicating permission management side of our application.
>> Since the capability of retrieving details of all devices is already
>> provided by a predefined role, now we do not have the
>> luxury of creating one single role having the same capability + another
>> set of capabilities simply because of the fact that a role cannot be
>> assigned to another role.
>> With this limitation, as of now if an administrator wants to assign a
>> user the capability of retrieving details of all devices + another set
>> of capabilities,
>> he cannot simply do that by assigning the user a single role, instead he
>> would need to assign at least two roles. This could get even worse
>> if we have the same issue for many other APIs as well. All this is
>> because we are violating the fundamental principals
>> and trying to authorize capabilities of our application directly via
>> roles instead of scopes or permissions.
>>
>> Cheers,
>> Dilan.
>>
>>
>>
>> *Dilan U. Ariyaratne*
>> Senior Software Engineer
>> WSO2 Inc. 
>> Mobile: +94766405580 <%2B94766405580>
>> lean . enterprise . middleware
>>
>>
>> On Mon, Aug 8, 2016 at 2:08 PM, Chathura Dilan 
>> wrote:
>>
>>> Hi Sam,
>>>
>>> Sometimes based on the scopes we might need to authorize the APIs to get
>>> different responses.
>>>
>>> Eg: Facebook scopes [1]. At the login we can send multiple scopes,
>>> generate the token and authorize an API based on scopes.
>>>
>>> It is not possible if only one scope is assigned to one API (resource).
>>>
>>> IMO scopes should be initially designed when the APIs are designed
>>> regardless of the roles that they would be attached to.
>>>
>>> [1] - https://developers.facebook.com/docs/facebook-login/permissions
>>>
>>>
>>>
>>> On Thu, Aug 4, 2016 at 1:41 PM, Milan Perera  wrote:
>>>
 Hi Sam,

 Thanks for the clarification.

 On Thu, Aug 4, 2016 at 12:34 PM, Sam Sivayogam  wrote:

> Hi Milan,
>
> In APIM scopes are there to give access controls based on user roles.
> A scope can contain multiple user roles so if you want to block multiple
> roles add those roles to a* single scope *and

Re: [Dev] [Architecture] [APIM] [EMM] Adding multiple scopes to a single API resource endpoint

[Dilan Udara Ariyaratne]

Hi Nuwan,

The responsibility of this authorization check could be assigned to either
one of the layers that you have mentioned.
Currently, we have assigned this responsibility to API layer of the backend
system.

Cheers,
Dilan.

*Dilan U. Ariyaratne*
Senior Software Engineer
WSO2 Inc. 
Mobile: +94766405580 <%2B94766405580>
lean . enterprise . middleware


On Tue, Aug 9, 2016 at 8:33 AM, Nuwan Dias  wrote:

> Whose responsibility is it to decide what details to return in the
> response based on the user who's requesting it? Is it the fronting API's
> responsibility to decide this or should it be the core back-end of the
> Application who should be deciding who gets what?
>
> On Tue, Aug 9, 2016 at 6:47 AM, Dilan Udara Ariyaratne 
> wrote:
>
>> Adding the thread to architecture, as this proposes an architectural
>> change to existing OAuth scopes @ APIM level.
>>
>> Regards,
>> Dilan.
>>
>> *Dilan U. Ariyaratne*
>> Senior Software Engineer
>> WSO2 Inc. 
>> Mobile: +94766405580 <%2B94766405580>
>> lean . enterprise . middleware
>>
>>
>> On Tue, Aug 9, 2016 at 6:30 AM, Dilan Udara Ariyaratne 
>> wrote:
>>
>>> Hi Sam,
>>>
>>> I also think that Chathura is making a valid point here.
>>>
>>> For example, let's take the exact problem that EMM APIs do have
>>> currently.
>>>
>>> I am considering GET /devices API here. For this API, we do have a
>>> requirement to compile two responses
>>> based on the type of user accessing the API.
>>>
>>> [1] If he is simply a device owner, he would only get the details of his
>>> own devices.
>>> [2] If he is an admin user, he would get the facility of retrieving all
>>> the devices for that particular tenant.
>>>
>>> Since we can currently map only one scope with an API endpoint, that can
>>> only be useful in verifying whether the particular user is capable
>>> of accessing the API endpoint or not. This one-to-one level of API
>>> scoping is not enough in identifying to
>>> which of the above two responses, the user is authorized to access.
>>>
>>> If we had one-to-many level of API scoping, the story is different.
>>> Then we can add two scopes like, get-owning-devices and get-all-devices
>>> to the API, let a user access the API first by having either of two scopes.
>>> Next, we can simply decide what response to be authorized based on which
>>> of the two scopes, user is having.
>>>
>>> Since we do not currently have this facility of one-to-many level of API
>>> scoping, to achieve the same functionality, we have now
>>> got to think of other alternatives. Two such alternatives are:
>>>
>>> [1] Splitting the GET /devices API to two different APIs such that each
>>> would cater one of the above two responses
>>> and bring in the mentioned scopes to each of them separately:
>>>
>>> Although this is doable, this seems like duplicating
>>> the same business logic in multiple APIs again and again.
>>>
>>> [2] Introducing a predefined role such as get-all-devices and validate
>>> what response to be compiled based on that.
>>> If the user accessing the API has this role, in addition to the assigned
>>> API scope, he would get the facility of retrieving all the devices
>>> for that particular tenant or otherwise,only get the details of his own
>>> devices:
>>>
>>> Although this also seems doable, now we are simply in a process of
>>> complicating permission management side of our application.
>>> Since the capability of retrieving details of all devices is already
>>> provided by a predefined role, now we do not have the
>>> luxury of creating one single role having the same capability + another
>>> set of capabilities simply because of the fact that a role cannot be
>>> assigned to another role.
>>> With this limitation, as of now if an administrator wants to assign a
>>> user the capability of retrieving details of all devices + another set
>>> of capabilities,
>>> he cannot simply do that by assigning the user a single role, instead he
>>> would need to assign at least two roles. This could get even worse
>>> if we have the same issue for many other APIs as well. All this is
>>> because we are violating the fundamental principals
>>> and trying to authorize capabilities of our application directly via
>>> roles instead of scopes or permissions.
>>>
>>> Cheers,
>>> Dilan.
>>>
>>>
>>>
>>> *Dilan U. Ariyaratne*
>>> Senior Software Engineer
>>> WSO2 Inc. 
>>> Mobile: +94766405580 <%2B94766405580>
>>> lean . enterprise . middleware
>>>
>>>
>>> On Mon, Aug 8, 2016 at 2:08 PM, Chathura Dilan 
>>> wrote:
>>>
 Hi Sam,

 Sometimes based on the scopes we might need to authorize the APIs to
 get different responses.

 Eg: Facebook scopes [1]. At the login we can send multiple scopes,
 generate the token and authorize an API based on scopes.

 It is not possible if only one scope is assigned to one API (resource).

 IMO scopes should be initially designed when the APIs are designed
 regard

Re: [Dev] [Architecture] [APIM] [EMM] Adding multiple scopes to a single API resource endpoint

[Nuwan Dias]

If you do that and depend on OAuth 2.0 scopes to determine the data to be
returned from your Application, you're basically tying a core Application
logic to the security protocol of the API. What happens if you later decide
to remove OAuth and use some other protocol to secure your API?

In my view the correct solution is to have the Application deal with this
logic and the fronting API layer should provide the Application the
necessary data it needs to make that decision. So in this context, the API
should create a JWT containing the data the App needs (permissions, roles,
claims or whatever) and provide the JWT to the Application. Since JWT is a
standard mechanism of of passing information between entities, it is not
tied to the security protocol of the API.

On Tue, Aug 9, 2016 at 6:25 PM, Dilan Udara Ariyaratne 
wrote:

> Hi Nuwan,
>
> The responsibility of this authorization check could be assigned to either
> one of the layers that you have mentioned.
> Currently, we have assigned this responsibility to API layer of the
> backend system.
>
> Cheers,
> Dilan.
>
> *Dilan U. Ariyaratne*
> Senior Software Engineer
> WSO2 Inc. 
> Mobile: +94766405580 <%2B94766405580>
> lean . enterprise . middleware
>
>
> On Tue, Aug 9, 2016 at 8:33 AM, Nuwan Dias  wrote:
>
>> Whose responsibility is it to decide what details to return in the
>> response based on the user who's requesting it? Is it the fronting API's
>> responsibility to decide this or should it be the core back-end of the
>> Application who should be deciding who gets what?
>>
>> On Tue, Aug 9, 2016 at 6:47 AM, Dilan Udara Ariyaratne 
>> wrote:
>>
>>> Adding the thread to architecture, as this proposes an architectural
>>> change to existing OAuth scopes @ APIM level.
>>>
>>> Regards,
>>> Dilan.
>>>
>>> *Dilan U. Ariyaratne*
>>> Senior Software Engineer
>>> WSO2 Inc. 
>>> Mobile: +94766405580 <%2B94766405580>
>>> lean . enterprise . middleware
>>>
>>>
>>> On Tue, Aug 9, 2016 at 6:30 AM, Dilan Udara Ariyaratne 
>>> wrote:
>>>
 Hi Sam,

 I also think that Chathura is making a valid point here.

 For example, let's take the exact problem that EMM APIs do have
 currently.

 I am considering GET /devices API here. For this API, we do have a
 requirement to compile two responses
 based on the type of user accessing the API.

 [1] If he is simply a device owner, he would only get the details of
 his own devices.
 [2] If he is an admin user, he would get the facility of retrieving all
 the devices for that particular tenant.

 Since we can currently map only one scope with an API endpoint, that
 can only be useful in verifying whether the particular user is capable
 of accessing the API endpoint or not. This one-to-one level of API
 scoping is not enough in identifying to
 which of the above two responses, the user is authorized to access.

 If we had one-to-many level of API scoping, the story is different.
 Then we can add two scopes like, get-owning-devices and get-all-devices
 to the API, let a user access the API first by having either of two scopes.
 Next, we can simply decide what response to be authorized based on
 which of the two scopes, user is having.

 Since we do not currently have this facility of one-to-many level of
 API scoping, to achieve the same functionality, we have now
 got to think of other alternatives. Two such alternatives are:

 [1] Splitting the GET /devices API to two different APIs such that each
 would cater one of the above two responses
 and bring in the mentioned scopes to each of them separately:

 Although this is doable, this seems like duplicating
 the same business logic in multiple APIs again and again.

 [2] Introducing a predefined role such as get-all-devices and validate
 what response to be compiled based on that.
 If the user accessing the API has this role, in addition to the
 assigned API scope, he would get the facility of retrieving all the devices
 for that particular tenant or otherwise,only get the details of his
 own devices:

 Although this also seems doable, now we are simply in a process of
 complicating permission management side of our application.
 Since the capability of retrieving details of all devices is already
 provided by a predefined role, now we do not have the
 luxury of creating one single role having the same capability + another
 set of capabilities simply because of the fact that a role cannot be
 assigned to another role.
 With this limitation, as of now if an administrator wants to assign a
 user the capability of retrieving details of all devices + another set
 of capabilities,
 he cannot simply do that by assigning the user a single role, instead
 he would need to assign at least two roles. This could get even worse