Re: [Architecture] [APIM] Admin REST API to check user role existence

[Meruja Selvamanikkam]

Hi all,

Please find the final definition as per offline discussion.

/settings/scopes/{scope}:
  #-
  # Retrieve scope settings
  #-
  get:
security:
  - OAuth2Security:
  - apim:admin_settings
x-wso2-curl: "curl -k -X GET
\"https://localhost:9443/api/am/admin/v1/settings/scopes/apim:subscribe?username=john\";
-H \"accept: application/json\" -H \"Authorization: Bearer
8e8edc50-4a70-3fec-af00-ce08097012ab"
x-wso2-request: "GET
https://localhost:9443/api/am/admin/v1/settings/scopes/apim:subscribe?username=john
Authorization: Bearer 8e8edc50-4a70-3fec-af00-ce08097012ab"
x-wso2-response: "{\n  \"name\":\"apim:subscribe\"  \n}\n"
summary: Retrieve scopes for a particular user
description: |
  This operation will return the scope list of particular user
  In order to get it, we need to pass the userId as a query parameter
parameters:
  - name: username
in: query
type: string
required: true
  - $ref : '#/parameters/scope'
tags:
  - Settings
responses:
  200:
description: |
  OK.
  Particular scope exists for the given user.
schema:
  $ref: '#/definitions/ScopeSettings'
  400:
description: |
  Bad Request.
  Invalid request or validation error
schema:
  $ref: '#/definitions/Error'
  404:
description: |
  Not Found.
  Requested user does not exist.
schema:
  $ref: '#/definitions/Error'

I have implemented the REST API for the above definition to check
whether the particular user has the particular scope or not.
PR for the REST API implementation can be found in [1] .

[1] - https://github.com/wso2/carbon-apimgt/pull/8605

Thanks & Regards
*S.Meruja* |Software Engineer | WSO2 Inc.
(m) +94779650506 | Email: mer...@wso2.com
Linkedin:   https://www.linkedin.com/in/meruja

Medium: https://medium.com/@meruja



On Sun, May 31, 2020 at 8:32 PM Frank Leymann  wrote:

> Sure, Meruja, that's what 412 is all about - but I didn't see documented
> that we support conditional requests, and what the semantics in our case
> will be: that's why I am asking.
>
> Best regards,
> Frank
>
>
>
>
> Am Di., 26. Mai 2020 um 06:56 Uhr schrieb Meruja Selvamanikkam <
> mer...@wso2.com>:
>
>> Dear Frank,
>>
>> We return 412 when the preconditions fail.
>> The number of request headers that can be used to apply conditions to a
>> request:
>>
>> If-Match
>> If-Modified-Since
>> If-None-Match
>> If-Range
>> If-Unmodified-Since
>>
>> Since my request does not contains the stated headers, there won't be 412.  
>> Thanks for pointing me to clarify and correct my understanding.
>>
>>  412:
>>   description: |
>> Precondition Failed.
>> The request has not been performed because one of the 
>> preconditions is not met.
>>   schema:
>> $ref: '#/definitions/Error'
>> This should be removed from the response.
>>
>> Thanks & Regards,
>> *S.Meruja* |Software Engineer | WSO2 Inc.
>> (m) +94779650506 | Email: mer...@wso2.com
>> Linkedin:   https://www.linkedin.com/in/meruja
>> 
>> Medium: https://medium.com/@meruja
>> 
>>
>>
>> On Mon, May 25, 2020 at 10:23 PM Frank Leymann  wrote:
>>
>>> Dear Meruja,
>>>
>>> when would we return a 412?
>>>
>>> Best regards,
>>> Frank
>>>
>>>
>>>
>>>
>>> Am Fr., 22. Mai 2020 um 15:42 Uhr schrieb Meruja Selvamanikkam <
>>> mer...@wso2.com>:
>>>
 Hi all,

 We are in the process of implementing an API to get the scope list of a
 particular user.
 Following will be the notations of the new API:
 *GET  api/am/admin/v1/settings/scopes?userId=*

 Please find the swagger definition below:

  /settings/scopes:
 #-
 # Retrieve scope settings
 #-
 get:
   security:
 - OAuth2Security:
 - apim:admin_settings
   x-wso2-curl: "curl -k -H \"Authorization: Bearer
 ae4eae22-3f65-387b-a171-d37eaa366fa8\" -X POST \"
 https://localhost:9443/api/am/admin/v1/settings/scopes?userId=890a4f4d-09eb-48
 
 ""
   x-wso2-request: |
 GET
 https://localhost:9443/api/am/admin/v1/settings/scopes?userId=890a4f4d-09eb-48
 
 Authorization: Bearer ae4eae22-3f65-387b-a171-d37eaa366fa8
   x-wso2-response: "HTTP/1.1 200 OK"
   summary: Re

Re: [Architecture] [APIM] Admin REST API to check user role existence

[Frank Leymann]

Sure, Meruja, that's what 412 is all about - but I didn't see documented
that we support conditional requests, and what the semantics in our case
will be: that's why I am asking.

Best regards,
Frank




Am Di., 26. Mai 2020 um 06:56 Uhr schrieb Meruja Selvamanikkam <
mer...@wso2.com>:

> Dear Frank,
>
> We return 412 when the preconditions fail.
> The number of request headers that can be used to apply conditions to a
> request:
>
> If-Match
> If-Modified-Since
> If-None-Match
> If-Range
> If-Unmodified-Since
>
> Since my request does not contains the stated headers, there won't be 412.  
> Thanks for pointing me to clarify and correct my understanding.
>
>  412:
>   description: |
> Precondition Failed.
> The request has not been performed because one of the 
> preconditions is not met.
>   schema:
> $ref: '#/definitions/Error'
> This should be removed from the response.
>
> Thanks & Regards,
> *S.Meruja* |Software Engineer | WSO2 Inc.
> (m) +94779650506 | Email: mer...@wso2.com
> Linkedin:   https://www.linkedin.com/in/meruja
> 
> Medium: https://medium.com/@meruja
> 
>
>
> On Mon, May 25, 2020 at 10:23 PM Frank Leymann  wrote:
>
>> Dear Meruja,
>>
>> when would we return a 412?
>>
>> Best regards,
>> Frank
>>
>>
>>
>>
>> Am Fr., 22. Mai 2020 um 15:42 Uhr schrieb Meruja Selvamanikkam <
>> mer...@wso2.com>:
>>
>>> Hi all,
>>>
>>> We are in the process of implementing an API to get the scope list of a
>>> particular user.
>>> Following will be the notations of the new API:
>>> *GET  api/am/admin/v1/settings/scopes?userId=*
>>>
>>> Please find the swagger definition below:
>>>
>>>  /settings/scopes:
>>> #-
>>> # Retrieve scope settings
>>> #-
>>> get:
>>>   security:
>>> - OAuth2Security:
>>> - apim:admin_settings
>>>   x-wso2-curl: "curl -k -H \"Authorization: Bearer
>>> ae4eae22-3f65-387b-a171-d37eaa366fa8\" -X POST \"
>>> https://localhost:9443/api/am/admin/v1/settings/scopes?userId=890a4f4d-09eb-48
>>> 
>>> ""
>>>   x-wso2-request: |
>>> GET
>>> https://localhost:9443/api/am/admin/v1/settings/scopes?userId=890a4f4d-09eb-48
>>> 
>>> Authorization: Bearer ae4eae22-3f65-387b-a171-d37eaa366fa8
>>>   x-wso2-response: "HTTP/1.1 200 OK"
>>>   summary: Retrieve scopes for a particular user
>>>   description: |
>>> This operation will return the scope list of particular user
>>> In order to get it, we need to pass the userId as a query
>>> parameter
>>>   parameters:
>>> - name: userId
>>>   in: query
>>>   type: string
>>>   required: true
>>>   tags:
>>> - Settings
>>>   responses:
>>> 200:
>>>   description: |
>>> OK.
>>> Scopes for a particular user retrieved successfully.
>>> 400:
>>>   description: |
>>> Bad Request.
>>> Invalid request or validation error
>>>   schema:
>>> $ref: '#/definitions/Error'
>>> 404:
>>>   description: |
>>> Not Found.
>>> Requested user does not exist.
>>>   schema:
>>> $ref: '#/definitions/Error'
>>> 412:
>>>   description: |
>>> Precondition Failed.
>>> The request has not been performed because one of the
>>> preconditions is not met.
>>>   schema:
>>> $ref: '#/definitions/Error'
>>>
>>> Highly appreciate your thoughts and suggestions.
>>>
>>> Thanks & Regards,
>>> *S.Meruja* |Software Engineer | WSO2 Inc.
>>> (m) +94779650506 | Email: mer...@wso2.com
>>> Linkedin:   https://www.linkedin.com/in/meruja
>>> 
>>> Medium: https://medium.com/@meruja
>>> 
>>>
>>>
>>> On Mon, May 11, 2020 at 9:37 PM Meruja Selvamanikkam 
>>> wrote:
>>>
  Hi all,

 Thank you for your suggestions

 I have a few concerns regarding validating the subscriber permissions
> of the input application owner using the default subscriber role(Internal
> subscriber). Since the REST API and portal access are based on the
> scope-role mapping which is maintained in tenant-conf.json, a subscriber
> user does not necessarily have the *Internal/subscriber* role. If a
> new role mapping to app management, subscriptions related scopes has been
> introduced with custom roles, then the validation should be done against
> those roles as well.
>

 I agree with you. For previous version

Re: [Architecture] [APIM] Admin REST API to check user role existence

[Meruja Selvamanikkam]

Dear Frank,

We return 412 when the preconditions fail.
The number of request headers that can be used to apply conditions to a
request:

If-Match
If-Modified-Since
If-None-Match
If-Range
If-Unmodified-Since

Since my request does not contains the stated headers, there won't be
412.  Thanks for pointing me to clarify and correct my understanding.

 412:
  description: |
Precondition Failed.
The request has not been performed because one of the
preconditions is not met.
  schema:
$ref: '#/definitions/Error'
This should be removed from the response.

Thanks & Regards,
*S.Meruja* |Software Engineer | WSO2 Inc.
(m) +94779650506 | Email: mer...@wso2.com
Linkedin:   https://www.linkedin.com/in/meruja

Medium: https://medium.com/@meruja



On Mon, May 25, 2020 at 10:23 PM Frank Leymann  wrote:

> Dear Meruja,
>
> when would we return a 412?
>
> Best regards,
> Frank
>
>
>
>
> Am Fr., 22. Mai 2020 um 15:42 Uhr schrieb Meruja Selvamanikkam <
> mer...@wso2.com>:
>
>> Hi all,
>>
>> We are in the process of implementing an API to get the scope list of a
>> particular user.
>> Following will be the notations of the new API:
>> *GET  api/am/admin/v1/settings/scopes?userId=*
>>
>> Please find the swagger definition below:
>>
>>  /settings/scopes:
>> #-
>> # Retrieve scope settings
>> #-
>> get:
>>   security:
>> - OAuth2Security:
>> - apim:admin_settings
>>   x-wso2-curl: "curl -k -H \"Authorization: Bearer
>> ae4eae22-3f65-387b-a171-d37eaa366fa8\" -X POST \"
>> https://localhost:9443/api/am/admin/v1/settings/scopes?userId=890a4f4d-09eb-48
>> 
>> ""
>>   x-wso2-request: |
>> GET
>> https://localhost:9443/api/am/admin/v1/settings/scopes?userId=890a4f4d-09eb-48
>> 
>> Authorization: Bearer ae4eae22-3f65-387b-a171-d37eaa366fa8
>>   x-wso2-response: "HTTP/1.1 200 OK"
>>   summary: Retrieve scopes for a particular user
>>   description: |
>> This operation will return the scope list of particular user
>> In order to get it, we need to pass the userId as a query
>> parameter
>>   parameters:
>> - name: userId
>>   in: query
>>   type: string
>>   required: true
>>   tags:
>> - Settings
>>   responses:
>> 200:
>>   description: |
>> OK.
>> Scopes for a particular user retrieved successfully.
>> 400:
>>   description: |
>> Bad Request.
>> Invalid request or validation error
>>   schema:
>> $ref: '#/definitions/Error'
>> 404:
>>   description: |
>> Not Found.
>> Requested user does not exist.
>>   schema:
>> $ref: '#/definitions/Error'
>> 412:
>>   description: |
>> Precondition Failed.
>> The request has not been performed because one of the
>> preconditions is not met.
>>   schema:
>> $ref: '#/definitions/Error'
>>
>> Highly appreciate your thoughts and suggestions.
>>
>> Thanks & Regards,
>> *S.Meruja* |Software Engineer | WSO2 Inc.
>> (m) +94779650506 | Email: mer...@wso2.com
>> Linkedin:   https://www.linkedin.com/in/meruja
>> 
>> Medium: https://medium.com/@meruja
>> 
>>
>>
>> On Mon, May 11, 2020 at 9:37 PM Meruja Selvamanikkam 
>> wrote:
>>
>>>  Hi all,
>>>
>>> Thank you for your suggestions
>>>
>>> I have a few concerns regarding validating the subscriber permissions of
 the input application owner using the default subscriber role(Internal
 subscriber). Since the REST API and portal access are based on the
 scope-role mapping which is maintained in tenant-conf.json, a subscriber
 user does not necessarily have the *Internal/subscriber* role. If a
 new role mapping to app management, subscriptions related scopes has been
 introduced with custom roles, then the validation should be done against
 those roles as well.

>>>
>>> I agree with you. For previous versions, we have a default subscriber
>>> role in the configuration file and checked role-based permission for a
>>> particular feature. From 3.1.0 onwards, we have a scope-role mapping.
>>> In this case, we cannot validate the user role.
>>>
>>> Hence, we should be validating whether any of the roles assigned to that
 particular user has bare scope based minimum access to API subscriptions,
 app management resources. So the validation should be based o

Re: [Architecture] [APIM] Admin REST API to check user role existence

[Frank Leymann]

Dear Meruja,

when would we return a 412?

Best regards,
Frank




Am Fr., 22. Mai 2020 um 15:42 Uhr schrieb Meruja Selvamanikkam <
mer...@wso2.com>:

> Hi all,
>
> We are in the process of implementing an API to get the scope list of a
> particular user.
> Following will be the notations of the new API:
> *GET  api/am/admin/v1/settings/scopes?userId=*
>
> Please find the swagger definition below:
>
>  /settings/scopes:
> #-
> # Retrieve scope settings
> #-
> get:
>   security:
> - OAuth2Security:
> - apim:admin_settings
>   x-wso2-curl: "curl -k -H \"Authorization: Bearer
> ae4eae22-3f65-387b-a171-d37eaa366fa8\" -X POST \"
> https://localhost:9443/api/am/admin/v1/settings/scopes?userId=890a4f4d-09eb-48
> 
> ""
>   x-wso2-request: |
> GET
> https://localhost:9443/api/am/admin/v1/settings/scopes?userId=890a4f4d-09eb-48
> 
> Authorization: Bearer ae4eae22-3f65-387b-a171-d37eaa366fa8
>   x-wso2-response: "HTTP/1.1 200 OK"
>   summary: Retrieve scopes for a particular user
>   description: |
> This operation will return the scope list of particular user
> In order to get it, we need to pass the userId as a query parameter
>   parameters:
> - name: userId
>   in: query
>   type: string
>   required: true
>   tags:
> - Settings
>   responses:
> 200:
>   description: |
> OK.
> Scopes for a particular user retrieved successfully.
> 400:
>   description: |
> Bad Request.
> Invalid request or validation error
>   schema:
> $ref: '#/definitions/Error'
> 404:
>   description: |
> Not Found.
> Requested user does not exist.
>   schema:
> $ref: '#/definitions/Error'
> 412:
>   description: |
> Precondition Failed.
> The request has not been performed because one of the
> preconditions is not met.
>   schema:
> $ref: '#/definitions/Error'
>
> Highly appreciate your thoughts and suggestions.
>
> Thanks & Regards,
> *S.Meruja* |Software Engineer | WSO2 Inc.
> (m) +94779650506 | Email: mer...@wso2.com
> Linkedin:   https://www.linkedin.com/in/meruja
> 
> Medium: https://medium.com/@meruja
> 
>
>
> On Mon, May 11, 2020 at 9:37 PM Meruja Selvamanikkam 
> wrote:
>
>>  Hi all,
>>
>> Thank you for your suggestions
>>
>> I have a few concerns regarding validating the subscriber permissions of
>>> the input application owner using the default subscriber role(Internal
>>> subscriber). Since the REST API and portal access are based on the
>>> scope-role mapping which is maintained in tenant-conf.json, a subscriber
>>> user does not necessarily have the *Internal/subscriber* role. If a new
>>> role mapping to app management, subscriptions related scopes has been
>>> introduced with custom roles, then the validation should be done against
>>> those roles as well.
>>>
>>
>> I agree with you. For previous versions, we have a default subscriber
>> role in the configuration file and checked role-based permission for a
>> particular feature. From 3.1.0 onwards, we have a scope-role mapping.
>> In this case, we cannot validate the user role.
>>
>> Hence, we should be validating whether any of the roles assigned to that
>>> particular user has bare scope based minimum access to API subscriptions,
>>> app management resources. So the validation should be based on the
>>> role-scope mapping.
>>>
>>> ie: If the user's role 'roleA' has role-scope mappings for 'apim:subscribe'
>>> and 'apim:app_manage' scopes, then that particular user is eligible as
>>> a new owner of a given application.
>>> WDYT?
>>>
>> Yes, we need to validate against the scope.
>>
>>
>> Thanks & Regards,
>> *S.Meruja* |Software Engineer | WSO2 Inc.
>> (m) +94779650506 | Email: mer...@wso2.com
>> Linkedin:   https://www.linkedin.com/in/meruja
>> 
>> Medium: https://medium.com/@meruja
>> 
>> ___
>> 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

Re: [Architecture] [APIM] Admin REST API to check user role existence

[Meruja Selvamanikkam]

Hi all,

We are in the process of implementing an API to get the scope list of a
particular user.
Following will be the notations of the new API:
*GET  api/am/admin/v1/settings/scopes?userId=*

Please find the swagger definition below:

 /settings/scopes:
#-
# Retrieve scope settings
#-
get:
  security:
- OAuth2Security:
- apim:admin_settings
  x-wso2-curl: "curl -k -H \"Authorization: Bearer
ae4eae22-3f65-387b-a171-d37eaa366fa8\" -X POST \"
https://localhost:9443/api/am/admin/v1/settings/scopes?userId=890a4f4d-09eb-48

""
  x-wso2-request: |
GET
https://localhost:9443/api/am/admin/v1/settings/scopes?userId=890a4f4d-09eb-48

Authorization: Bearer ae4eae22-3f65-387b-a171-d37eaa366fa8
  x-wso2-response: "HTTP/1.1 200 OK"
  summary: Retrieve scopes for a particular user
  description: |
This operation will return the scope list of particular user
In order to get it, we need to pass the userId as a query parameter
  parameters:
- name: userId
  in: query
  type: string
  required: true
  tags:
- Settings
  responses:
200:
  description: |
OK.
Scopes for a particular user retrieved successfully.
400:
  description: |
Bad Request.
Invalid request or validation error
  schema:
$ref: '#/definitions/Error'
404:
  description: |
Not Found.
Requested user does not exist.
  schema:
$ref: '#/definitions/Error'
412:
  description: |
Precondition Failed.
The request has not been performed because one of the
preconditions is not met.
  schema:
$ref: '#/definitions/Error'

Highly appreciate your thoughts and suggestions.

Thanks & Regards,
*S.Meruja* |Software Engineer | WSO2 Inc.
(m) +94779650506 | Email: mer...@wso2.com
Linkedin:   https://www.linkedin.com/in/meruja

Medium: https://medium.com/@meruja



On Mon, May 11, 2020 at 9:37 PM Meruja Selvamanikkam 
wrote:

>  Hi all,
>
> Thank you for your suggestions
>
> I have a few concerns regarding validating the subscriber permissions of
>> the input application owner using the default subscriber role(Internal
>> subscriber). Since the REST API and portal access are based on the
>> scope-role mapping which is maintained in tenant-conf.json, a subscriber
>> user does not necessarily have the *Internal/subscriber* role. If a new
>> role mapping to app management, subscriptions related scopes has been
>> introduced with custom roles, then the validation should be done against
>> those roles as well.
>>
>
> I agree with you. For previous versions, we have a default subscriber role
> in the configuration file and checked role-based permission for a
> particular feature. From 3.1.0 onwards, we have a scope-role mapping.
> In this case, we cannot validate the user role.
>
> Hence, we should be validating whether any of the roles assigned to that
>> particular user has bare scope based minimum access to API subscriptions,
>> app management resources. So the validation should be based on the
>> role-scope mapping.
>>
>> ie: If the user's role 'roleA' has role-scope mappings for 'apim:subscribe'
>> and 'apim:app_manage' scopes, then that particular user is eligible as a
>> new owner of a given application.
>> WDYT?
>>
> Yes, we need to validate against the scope.
>
>
> Thanks & Regards,
> *S.Meruja* |Software Engineer | WSO2 Inc.
> (m) +94779650506 | Email: mer...@wso2.com
> Linkedin:   https://www.linkedin.com/in/meruja
> 
> Medium: https://medium.com/@meruja
> 
> ___
> 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

Re: [Architecture] [APIM] Admin REST API to check user role existence

[Meruja Selvamanikkam]

 Hi all,

Thank you for your suggestions

I have a few concerns regarding validating the subscriber permissions of
> the input application owner using the default subscriber role(Internal
> subscriber). Since the REST API and portal access are based on the
> scope-role mapping which is maintained in tenant-conf.json, a subscriber
> user does not necessarily have the *Internal/subscriber* role. If a new
> role mapping to app management, subscriptions related scopes has been
> introduced with custom roles, then the validation should be done against
> those roles as well.
>

I agree with you. For previous versions, we have a default subscriber role
in the configuration file and checked role-based permission for a
particular feature. From 3.1.0 onwards, we have a scope-role mapping.
In this case, we cannot validate the user role.

Hence, we should be validating whether any of the roles assigned to that
> particular user has bare scope based minimum access to API subscriptions,
> app management resources. So the validation should be based on the
> role-scope mapping.
>
> ie: If the user's role 'roleA' has role-scope mappings for 'apim:subscribe'
> and 'apim:app_manage' scopes, then that particular user is eligible as a
> new owner of a given application.
> WDYT?
>
Yes, we need to validate against the scope.


Thanks & Regards,
*S.Meruja* |Software Engineer | WSO2 Inc.
(m) +94779650506 | Email: mer...@wso2.com
Linkedin:   https://www.linkedin.com/in/meruja

Medium: https://medium.com/@meruja

___
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

Re: [Architecture] [APIM] Admin REST API to check user role existence

[Frank Leymann]

Dear Malintha,

my responses below

Best regards,
Frank




Am Mi., 6. Mai 2020 um 08:40 Uhr schrieb Malintha Amarasinghe <
malint...@wso2.com>:

> Dear Frank,
>
> Thank you for looking into this.
>

It is my pleasure :-)


>
> On Tue, May 5, 2020 at 1:48 PM Frank Leymann  wrote:
>
>> Dear Meruja,
>>
>> the URI of the second API (i.e.  /me/roles/{roleName}) is really
>> debatable: the intent of the */me* part of the URI seems to be to
>> identify the logged-in user, and to me, such a user is a resource.
>>
> I may be a little bit deviating from the original question.
>

Let me add to the above:  a URI, e.g. /me, always points to a single, a
unique resource. Thus, /me would point to exactly one person - we can't use
/me as an abstraction for all users implicitly picking the one who is
currently in the context (i.e. logged-in), that would counter the concept
of a URI as an identifier.

If we use a resource like /me, if we consider we do GET for that, we'll get
> the "me" resource which will return the logged in user details: eg:
> {
>"uid": "malintha"
>"fullName": "Malintha Amarasinghe"
>"mobile: "..",
>"roles" : [
>{
>   "name" : "Internal/subscriber",
>   "type": "Internal"
>}, {
>{
>   "name" : "app-manager",
>   "type": "Primary"
>}
>],
>...
> }
>
> In the above resource, I was under the impression that we consider "roles"
> as a sub-resource of /me. For example: if we did a GET for /me/roles we
> could return:
> {
> "count" : 2,
> "list": [
>{
>   "name" : "Internal/subscriber",
>   "type": "Internal"
>}, {
>{
>   "name" : "app-manager",
>   "type": "Primary"
>}
>]
> }
>
> I think /me/roles/{roleName} may not make sense here because we could just
> do /roles/{roleName} to get the role details.
>

Just using  /roles/{roleName} would return the details of the specified
role itself, without any reference to the logged-in user, i.e. the context
has to contain the user itself.


> Instead, I was under impression that we can use  /me/roles?{roleName} to
> check if a particular role is available to the logged-in user.
>

...and, yes, you are absolutely right, "role" is a query parameter, i.e.
.../roles?{roleName} is the correct syntax (I left out the /me part by will
;-)).


>
> Would the above approaches be wrong? If so, if I need to get the roles of
> a particular user, should I only use an approach like /roles?{UserID}?
>

/roles?{UserId} will work too, but it would return all roles of the
specified user.

>
>
> I.e I assume that a user is represented in APIM as a resource (but I
>> didn't check the current API), or has a unique UserID - correct?
>>
>
> Yes, that is correct. But here, if we only need to represent the logged-in
> user, would it be ok if we have a resource /me (which represents a single
> resource for /users/)?. In that case, that doesn't take
> username as an input and we don't need to validate whether the user has
> provided his username instead of providing a different one.
>

As argued above, a URI is not abstract, i.e. it can not point to different
resources (users in this case).  Even worse, if multiple users use the API
at the same time, the "/me" URI would identify (!) different users at the
same time: which shows that it's no longer an identifier.


>
>
>> Thus, the URI of the API should be something like
>> .../users/{UserID}?{roleName}  or  /roles/{roleName}?{UserID}.
>>
>
> In this case, are we adding a filter for /users/{UserID} resource?
>

Yes, the query parameter ?{UserID} would act as a filter


> Which means if we did a GET /users/malintha?roleName=subscriber, should we
> give a 404 or 204?
>

Yes, we'll return a 404 if  GET .../users/{UserID}?{roleName}  did not find
the roleName specified for the UserID.  But should more specific, returning

   - a 403 Forbidden if the user is not allowed to issue this request (e.g.
   because User_1 wants to check the role of User_2 - but I don't know whether
   this is in sope of our application semantics)
   - a 401 Unauthorized if the user has to authenticate him/herself, or
   when authentication failed. But I am not sure whether this may happen
   because of the "security" header, i.e. whether this has been verified
   before.


> Can you kindly elaborate on this?
> I am sorry about asking multiple questions :( but thought of asking all as
> this will be helpful for us when designing new resources in the future too.
>

Continue asking questions: that's how we can jointly learn and build
fantastic products!  If you want, you can send questions whenever you are
in doubt about design decision - I am happy to help  :-))


>
> Thanks!
> Malintha
>
>
>>
>> Best regards,
>> Frank
>>
>>
>
>
>>
>>
>>
>> Am Di., 5. Mai 2020 um 06:17 Uhr schrieb Meruja Selvamanikkam <
>> mer...@wso2.com>:
>>
>>> Hi All,
>>>
>>> We are planning to add a REST API endpoint to APIM 3.2.0 Admin Rest A

Re: [Architecture] [APIM] Admin REST API to check user role existence

[Malintha Amarasinghe]

Dear Frank,

Thank you very much.
Please find my inline response.

On Sat, May 9, 2020 at 2:22 PM Frank Leymann  wrote:

> Dear Malintha,
>
> my responses below
>
> Best regards,
> Frank
>
>
>
>
> Am Mi., 6. Mai 2020 um 08:40 Uhr schrieb Malintha Amarasinghe <
> malint...@wso2.com>:
>
>> Dear Frank,
>>
>> Thank you for looking into this.
>>
>
> It is my pleasure :-)
>
>
>>
>> On Tue, May 5, 2020 at 1:48 PM Frank Leymann  wrote:
>>
>>> Dear Meruja,
>>>
>>> the URI of the second API (i.e.  /me/roles/{roleName}) is really
>>> debatable: the intent of the */me* part of the URI seems to be to
>>> identify the logged-in user, and to me, such a user is a resource.
>>>
>> I may be a little bit deviating from the original question.
>>
>
> Let me add to the above:  a URI, e.g. /me, always points to a single, a
> unique resource. Thus, /me would point to exactly one person - we can't use
> /me as an abstraction for all users implicitly picking the one who is
> currently in the context (i.e. logged-in), that would counter the concept
> of a URI as an identifier.
>

I think this was copied from the SCIM spec /Me endpoint (
https://tools.ietf.org/html/rfc7644#page-66).
I did some search regarding this and I found several responses saying "*any
information that can be named can be a resource" *as per Roy Thomas
Fielding's dissertation.
It also says "A resource is a conceptual mapping to a set of entities, not
the entity that corresponds to the mapping at any particular point in time."

So according to this, can we consider that "the logged-in user from the
context" as a conceptual mapping? (I am not sure I have correctly
understood the word conceptual mapping :( ) If that is true, we can
consider that as a resource.
In that case, /me would be the unified locator for that conceptual mapping?

https://stackoverflow.com/questions/36520372/designing-uri-for-current-logged-in-user-in-rest-applications
https://www.ics.uci.edu/~fielding/pubs/dissertation/rest_arch_style.htm#sec_5_2_1_1


> If we use a resource like /me, if we consider we do GET for that, we'll
>> get the "me" resource which will return the logged in user details: eg:
>> {
>>"uid": "malintha"
>>"fullName": "Malintha Amarasinghe"
>>"mobile: "..",
>>"roles" : [
>>{
>>   "name" : "Internal/subscriber",
>>   "type": "Internal"
>>}, {
>>{
>>   "name" : "app-manager",
>>   "type": "Primary"
>>}
>>],
>>...
>> }
>>
>> In the above resource, I was under the impression that we consider
>> "roles" as a sub-resource of /me. For example: if we did a GET
>> for /me/roles we could return:
>> {
>> "count" : 2,
>> "list": [
>>{
>>   "name" : "Internal/subscriber",
>>   "type": "Internal"
>>}, {
>>{
>>   "name" : "app-manager",
>>   "type": "Primary"
>>}
>>]
>> }
>>
>> I think /me/roles/{roleName} may not make sense here because we could
>> just do /roles/{roleName} to get the role details.
>>
>
> Just using  /roles/{roleName} would return the details of the specified
> role itself, without any reference to the logged-in user, i.e. the context
> has to contain the user itself.
>
>
>> Instead, I was under impression that we can use  /me/roles?{roleName} to
>> check if a particular role is available to the logged-in user.
>>
>
> ...and, yes, you are absolutely right, "role" is a query parameter, i.e.
> .../roles?{roleName} is the correct syntax (I left out the /me part by will
> ;-)).
>
>
>>
>> Would the above approaches be wrong? If so, if I need to get the roles of
>> a particular user, should I only use an approach like /roles?{UserID}?
>>
>
> /roles?{UserId} will work too, but it would return all roles of the
> specified user.
>

Well noted above responses.


>>
>> I.e I assume that a user is represented in APIM as a resource (but I
>>> didn't check the current API), or has a unique UserID - correct?
>>>
>>
>> Yes, that is correct. But here, if we only need to represent the
>> logged-in user, would it be ok if we have a resource /me (which represents
>> a single resource for /users/)?. In that case, that doesn't
>> take username as an input and we don't need to validate whether the user
>> has provided his username instead of providing a different one.
>>
>
> As argued above, a URI is not abstract, i.e. it can not point to different
> resources (users in this case).  Even worse, if multiple users use the API
> at the same time, the "/me" URI would identify (!) different users at the
> same time: which shows that it's no longer an identifier.
>
>
>>
>>
>>> Thus, the URI of the API should be something like
>>> .../users/{UserID}?{roleName}  or  /roles/{roleName}?{UserID}.
>>>
>>
>> In this case, are we adding a filter for /users/{UserID} resource?
>>
>
> Yes, the query parameter ?{UserID} would act as a filter
>
>
>> Which means if we did a GET /users/malintha?roleName=subscriber, should
>> we give a 404 or 204?
>>

Re: [Architecture] [APIM] Admin REST API to check user role existence

[Sanjeewa Malalgoda]

If we are to check the existence of a specific role, then using a role name
is not a good idea. Using role ID will be a better option.
And roles usually have "/" and we will need to check the impact of role
name resolving when / present in name. Have we checked that part. Reason is
/ have specific meaning in urls.

Thanks
sanjeewa.



On Mon, May 11, 2020 at 3:54 PM Thilini Shanika  wrote:

> Hi Meruja,
>
> I have a few concerns regarding validating the subscriber permissions of
> the input application owner using the default subscriber role(Internal
> subscriber). Since the REST API and portal access are based on the
> scope-role mapping which is maintained in tenant-conf.json, a subscriber
> user does not necessarily have the *Internal/subscriber* role. If a new
> role mapping to app management, subscriptions related scopes has been
> introduced with custom roles, then the validation should be done against
> those roles as well.
>
> Hence, we should be validating whether any of the roles assigned to that
> particular user has bare scope based minimum access to API subscriptions,
> app management resources. So the validation should be based on the
> role-scope mapping.
>
> ie: If the user's role 'roleA' has role-scope mappings for 'apim:subscribe'
> and 'apim:app_manage' scopes, then that particular user is eligible as a
> new owner of a given application.
> WDYT?
>
>
>
> On Wed, May 6, 2020 at 1:29 AM Thilini Shanika  wrote:
>
>>
>>
>> On Tue, May 5, 2020 at 11:36 AM Vithursa Mahendrarajah 
>> wrote:
>>
>>> Hi Meruja,
>>>
>>> The Publisher REST APIs for role validation is used to check whether
>>> the given role exists and the logged-in user has the given role. Here
>>> the role is taken from the user input, AFAIU the requirement, in this case
>>> we need to check whether the new user has the subscriber role before
>>> changing the application owner. Please correct if it is wrong.
>>>
>>> Since we need to validate whether the user has only a particular role,
>>> we do not need to have roleId in the resource path. Shall we have a
>>> resource name like /user/validate-subscriber-role. WDYT?
>>>
>>> Yes, you are correct. The requirement we are going to address through
>> the first API is to check whether the input username of the app owner has a
>> particular role(subscriber in this case). Hence, appowner name should be an
>> input to the first API. So I would suggest modifying the API resource as
>> follows.
>> /roles/{roleName}?{UserID}
>>
>>
>>
>>> Thanks,
>>> Vithursa
>>>
>>>
>>> On Tue, May 5, 2020 at 9:47 AM Meruja Selvamanikkam 
>>> wrote:
>>>
 Hi All,

 We are planning to add a REST API endpoint to APIM 3.2.0 Admin Rest
 APIs and the intention is to check the existence of a particular role name
 ( Internal/subscriber) when transferring ownership of an application to a
 user. We have similar API in the publisher to check the availability
 of the role[1].
 We have to decide the OAuth2 scope which functionalities are used by
 Admin.

 The swagger definition for the new endpoint would be as follows:

 ##
 # The Role Name Existence
 ##
   /roles/{roleName}:
 #-
 # The role name existence check resource
 #-
 head:
   security:
 - OAuth2Security:
 - apim:
   summary:
 Check given role name already exists
   description:
 Using this operation, to check whether given role already exists
   parameters:
 - $ref : '#/parameters/roleName'
   responses:
 200:
   description:
 OK.
 Requested role name is returned.
 404:
   description:
 Not Found.
 Requested role name does not exist.

 ##
 # The Role Name Existence for the logged-in user
 ##
   /me/roles/{roleName}:
 #-
 # Validate role against a user
 #-
 head:
   security:
 - OAuth2Security:
 - apim:
   summary:
 Validate whether the logged-in user has the given role
   description:
 Using this operation, logged-in user can check whether he has 
 given role.
   parameters:
 - $ref : '#/parameters/roleName'
   responses:
 200:
   description:
 OK.
 Logged-in user has the role.
 404:
   description:
 Not Found.
   

Re: [Architecture] [APIM] Admin REST API to check user role existence

[Thilini Shanika]

Hi Meruja,

I have a few concerns regarding validating the subscriber permissions of
the input application owner using the default subscriber role(Internal
subscriber). Since the REST API and portal access are based on the
scope-role mapping which is maintained in tenant-conf.json, a subscriber
user does not necessarily have the *Internal/subscriber* role. If a new
role mapping to app management, subscriptions related scopes has been
introduced with custom roles, then the validation should be done against
those roles as well.

Hence, we should be validating whether any of the roles assigned to that
particular user has bare scope based minimum access to API subscriptions,
app management resources. So the validation should be based on the
role-scope mapping.

ie: If the user's role 'roleA' has role-scope mappings for 'apim:subscribe'
and 'apim:app_manage' scopes, then that particular user is eligible as a
new owner of a given application.
WDYT?



On Wed, May 6, 2020 at 1:29 AM Thilini Shanika  wrote:

>
>
> On Tue, May 5, 2020 at 11:36 AM Vithursa Mahendrarajah 
> wrote:
>
>> Hi Meruja,
>>
>> The Publisher REST APIs for role validation is used to check whether the 
>> given
>> role exists and the logged-in user has the given role. Here the role is
>> taken from the user input, AFAIU the requirement, in this case we need to
>> check whether the new user has the subscriber role before changing the
>> application owner. Please correct if it is wrong.
>>
>> Since we need to validate whether the user has only a particular role, we
>> do not need to have roleId in the resource path. Shall we have a resource
>> name like /user/validate-subscriber-role. WDYT?
>>
>> Yes, you are correct. The requirement we are going to address through the
> first API is to check whether the input username of the app owner has a
> particular role(subscriber in this case). Hence, appowner name should be an
> input to the first API. So I would suggest modifying the API resource as
> follows.
> /roles/{roleName}?{UserID}
>
>
>
>> Thanks,
>> Vithursa
>>
>>
>> On Tue, May 5, 2020 at 9:47 AM Meruja Selvamanikkam 
>> wrote:
>>
>>> Hi All,
>>>
>>> We are planning to add a REST API endpoint to APIM 3.2.0 Admin Rest APIs
>>> and the intention is to check the existence of a particular role name (
>>> Internal/subscriber) when transferring ownership of an application to a
>>> user. We have similar API in the publisher to check the availability of
>>> the role[1].
>>> We have to decide the OAuth2 scope which functionalities are used by
>>> Admin.
>>>
>>> The swagger definition for the new endpoint would be as follows:
>>>
>>> ##
>>> # The Role Name Existence
>>> ##
>>>   /roles/{roleName}:
>>> #-
>>> # The role name existence check resource
>>> #-
>>> head:
>>>   security:
>>> - OAuth2Security:
>>> - apim:
>>>   summary:
>>> Check given role name already exists
>>>   description:
>>> Using this operation, to check whether given role already exists
>>>   parameters:
>>> - $ref : '#/parameters/roleName'
>>>   responses:
>>> 200:
>>>   description:
>>> OK.
>>> Requested role name is returned.
>>> 404:
>>>   description:
>>> Not Found.
>>> Requested role name does not exist.
>>>
>>> ##
>>> # The Role Name Existence for the logged-in user
>>> ##
>>>   /me/roles/{roleName}:
>>> #-
>>> # Validate role against a user
>>> #-
>>> head:
>>>   security:
>>> - OAuth2Security:
>>> - apim:
>>>   summary:
>>> Validate whether the logged-in user has the given role
>>>   description:
>>> Using this operation, logged-in user can check whether he has given 
>>> role.
>>>   parameters:
>>> - $ref : '#/parameters/roleName'
>>>   responses:
>>> 200:
>>>   description:
>>> OK.
>>> Logged-in user has the role.
>>> 404:
>>>   description:
>>> Not Found.
>>> Logged-in user does not have the role.
>>>
>>> Appreciate any feedback on this and correct me if I am wrong.
>>>
>>> [1] - [APIM-3.0] Publisher rest API to check a role name existence
>>>
>>> Thanks & Regards,
>>> *S.Meruja* |Software Engineer | WSO2 Inc.
>>> (m) +94779650506 | Email: mer...@wso2.com
>>> Linkedin:   https://www.linkedin.com/in/meruja
>>> 
>>> Medium: https://medium.com/@meruja
>>> 
>>> 

Re: [Architecture] [APIM] Admin REST API to check user role existence

[Malintha Amarasinghe]

Dear Frank,

Thank you for looking into this.

On Tue, May 5, 2020 at 1:48 PM Frank Leymann  wrote:

> Dear Meruja,
>
> the URI of the second API (i.e.  /me/roles/{roleName}) is really
> debatable: the intent of the */me* part of the URI seems to be to
> identify the logged-in user, and to me, such a user is a resource.
>
I may be a little bit deviating from the original question.
If we use a resource like /me, if we consider we do GET for that, we'll get
the "me" resource which will return the logged in user details: eg:
{
   "uid": "malintha"
   "fullName": "Malintha Amarasinghe"
   "mobile: "..",
   "roles" : [
   {
  "name" : "Internal/subscriber",
  "type": "Internal"
   }, {
   {
  "name" : "app-manager",
  "type": "Primary"
   }
   ],
   ...
}

In the above resource, I was under the impression that we consider "roles"
as a sub-resource of /me. For example: if we did a GET for /me/roles we
could return:
{
"count" : 2,
"list": [
   {
  "name" : "Internal/subscriber",
  "type": "Internal"
   }, {
   {
  "name" : "app-manager",
  "type": "Primary"
   }
   ]
}

I think /me/roles/{roleName} may not make sense here because we could just
do /roles/{roleName} to get the role details.
Instead, I was under impression that we can use  /me/roles?{roleName} to
check if a particular role is available to the logged-in user.

Would the above approaches be wrong? If so, if I need to get the roles of a
particular user, should I only use an approach like /roles?{UserID}?


I.e I assume that a user is represented in APIM as a resource (but I didn't
> check the current API), or has a unique UserID - correct?
>

Yes, that is correct. But here, if we only need to represent the logged-in
user, would it be ok if we have a resource /me (which represents a single
resource for /users/)?. In that case, that doesn't take
username as an input and we don't need to validate whether the user has
provided his username instead of providing a different one.


> Thus, the URI of the API should be something like
> .../users/{UserID}?{roleName}  or  /roles/{roleName}?{UserID}.
>

In this case, are we adding a filter for /users/{UserID} resource?
Which means if we did a GET /users/malintha?roleName=subscriber, should we
give a 404 or 204?

Can you kindly elaborate on this?
I am sorry about asking multiple questions :( but thought of asking all as
this will be helpful for us when designing new resources in the future too.

Thanks!
Malintha


>
> Best regards,
> Frank
>
>


>
>
>
> Am Di., 5. Mai 2020 um 06:17 Uhr schrieb Meruja Selvamanikkam <
> mer...@wso2.com>:
>
>> Hi All,
>>
>> We are planning to add a REST API endpoint to APIM 3.2.0 Admin Rest APIs
>> and the intention is to check the existence of a particular role name (
>> Internal/subscriber) when transferring ownership of an application to a
>> user. We have similar API in the publisher to check the availability of
>> the role[1].
>> We have to decide the OAuth2 scope which functionalities are used by Admin
>> .
>>
>> The swagger definition for the new endpoint would be as follows:
>>
>> ##
>> # The Role Name Existence
>> ##
>>   /roles/{roleName}:
>> #-
>> # The role name existence check resource
>> #-
>> head:
>>   security:
>> - OAuth2Security:
>> - apim:
>>   summary:
>> Check given role name already exists
>>   description:
>> Using this operation, to check whether given role already exists
>>   parameters:
>> - $ref : '#/parameters/roleName'
>>   responses:
>> 200:
>>   description:
>> OK.
>> Requested role name is returned.
>> 404:
>>   description:
>> Not Found.
>> Requested role name does not exist.
>>
>> ##
>> # The Role Name Existence for the logged-in user
>> ##
>>   /me/roles/{roleName}:
>> #-
>> # Validate role against a user
>> #-
>> head:
>>   security:
>> - OAuth2Security:
>> - apim:
>>   summary:
>> Validate whether the logged-in user has the given role
>>   description:
>> Using this operation, logged-in user can check whether he has given 
>> role.
>>   parameters:
>> - $ref : '#/parameters/roleName'
>>   responses:
>> 200:
>>   description:
>> OK.
>> Logged-in user has the role.
>> 404:
>>   description:
>> Not Found.
>> Logged-in user does not have the role.
>>

Re: [Architecture] [APIM] Admin REST API to check user role existence

[Thilini Shanika]

On Tue, May 5, 2020 at 11:36 AM Vithursa Mahendrarajah 
wrote:

> Hi Meruja,
>
> The Publisher REST APIs for role validation is used to check whether the given
> role exists and the logged-in user has the given role. Here the role is
> taken from the user input, AFAIU the requirement, in this case we need to
> check whether the new user has the subscriber role before changing the
> application owner. Please correct if it is wrong.
>
> Since we need to validate whether the user has only a particular role, we
> do not need to have roleId in the resource path. Shall we have a resource
> name like /user/validate-subscriber-role. WDYT?
>
> Yes, you are correct. The requirement we are going to address through the
first API is to check whether the input username of the app owner has a
particular role(subscriber in this case). Hence, appowner name should be an
input to the first API. So I would suggest modifying the API resource as
follows.
/roles/{roleName}?{UserID}



> Thanks,
> Vithursa
>
>
> On Tue, May 5, 2020 at 9:47 AM Meruja Selvamanikkam 
> wrote:
>
>> Hi All,
>>
>> We are planning to add a REST API endpoint to APIM 3.2.0 Admin Rest APIs
>> and the intention is to check the existence of a particular role name (
>> Internal/subscriber) when transferring ownership of an application to a
>> user. We have similar API in the publisher to check the availability of
>> the role[1].
>> We have to decide the OAuth2 scope which functionalities are used by Admin
>> .
>>
>> The swagger definition for the new endpoint would be as follows:
>>
>> ##
>> # The Role Name Existence
>> ##
>>   /roles/{roleName}:
>> #-
>> # The role name existence check resource
>> #-
>> head:
>>   security:
>> - OAuth2Security:
>> - apim:
>>   summary:
>> Check given role name already exists
>>   description:
>> Using this operation, to check whether given role already exists
>>   parameters:
>> - $ref : '#/parameters/roleName'
>>   responses:
>> 200:
>>   description:
>> OK.
>> Requested role name is returned.
>> 404:
>>   description:
>> Not Found.
>> Requested role name does not exist.
>>
>> ##
>> # The Role Name Existence for the logged-in user
>> ##
>>   /me/roles/{roleName}:
>> #-
>> # Validate role against a user
>> #-
>> head:
>>   security:
>> - OAuth2Security:
>> - apim:
>>   summary:
>> Validate whether the logged-in user has the given role
>>   description:
>> Using this operation, logged-in user can check whether he has given 
>> role.
>>   parameters:
>> - $ref : '#/parameters/roleName'
>>   responses:
>> 200:
>>   description:
>> OK.
>> Logged-in user has the role.
>> 404:
>>   description:
>> Not Found.
>> Logged-in user does not have the role.
>>
>> Appreciate any feedback on this and correct me if I am wrong.
>>
>> [1] - [APIM-3.0] Publisher rest API to check a role name existence
>>
>> Thanks & Regards,
>> *S.Meruja* |Software Engineer | WSO2 Inc.
>> (m) +94779650506 | Email: mer...@wso2.com
>> Linkedin:   https://www.linkedin.com/in/meruja
>> 
>> Medium: https://medium.com/@meruja
>> 
>> ___
>> Architecture mailing list
>> Architecture@wso2.org
>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>
>
>
> --
> *Vithursa Mahendrarajah* | Senior Software Engineer | WSO2 Inc
> (m) +94 766 695 643 | (e) vithu...@wso2.com
>
> * [image: https://wso2.com/signature]
> *
>


-- 
Thilini Shanika
Technical Lead
WSO2, Inc.; http://wso2.com
20, Palmgrove Avenue, Colombo 3
Mobile: +94710892258
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] [APIM] Admin REST API to check user role existence

[Shammi Jayasinghe]

Hi,

If we introduce this API in a way like we have [1] where we can get all the
available roles of the given user, does it create security risk ( Any way
we this is an Admin API right?). If we can get all the available roles, we
can validate it at the client side in this case. At the sametime, this api
may be very useful in customizations where the user does not need to
specifically pass the role name to validate. WDYT?

[1]
https://is.docs.wso2.com/en/5.9.0/develop/managing-users-and-roles-with-apis/#getrolelistofuser

Thanks
Shammi

On Tue, May 5, 2020 at 1:18 AM Frank Leymann  wrote:

> Dear Meruja,
>
> the URI of the second API (i.e.  /me/roles/{roleName}) is really
> debatable: the intent of the */me* part of the URI seems to be to
> identify the logged-in user, and to me, such a user is a resource. I.e I
> assume that a user is represented in APIM as a resource (but I didn't check
> the current API), or has a unique UserID - correct?
>
> Thus, the URI of the API should be something like
> .../users/{UserID}?{roleName}  or  /roles/{roleName}?{UserID}.
>
> Best regards,
> Frank
>
>
>
>
> Am Di., 5. Mai 2020 um 06:17 Uhr schrieb Meruja Selvamanikkam <
> mer...@wso2.com>:
>
>> Hi All,
>>
>> We are planning to add a REST API endpoint to APIM 3.2.0 Admin Rest APIs
>> and the intention is to check the existence of a particular role name (
>> Internal/subscriber) when transferring ownership of an application to a
>> user. We have similar API in the publisher to check the availability of
>> the role[1].
>> We have to decide the OAuth2 scope which functionalities are used by Admin
>> .
>>
>> The swagger definition for the new endpoint would be as follows:
>>
>> ##
>> # The Role Name Existence
>> ##
>>   /roles/{roleName}:
>> #-
>> # The role name existence check resource
>> #-
>> head:
>>   security:
>> - OAuth2Security:
>> - apim:
>>   summary:
>> Check given role name already exists
>>   description:
>> Using this operation, to check whether given role already exists
>>   parameters:
>> - $ref : '#/parameters/roleName'
>>   responses:
>> 200:
>>   description:
>> OK.
>> Requested role name is returned.
>> 404:
>>   description:
>> Not Found.
>> Requested role name does not exist.
>>
>> ##
>> # The Role Name Existence for the logged-in user
>> ##
>>   /me/roles/{roleName}:
>> #-
>> # Validate role against a user
>> #-
>> head:
>>   security:
>> - OAuth2Security:
>> - apim:
>>   summary:
>> Validate whether the logged-in user has the given role
>>   description:
>> Using this operation, logged-in user can check whether he has given 
>> role.
>>   parameters:
>> - $ref : '#/parameters/roleName'
>>   responses:
>> 200:
>>   description:
>> OK.
>> Logged-in user has the role.
>> 404:
>>   description:
>> Not Found.
>> Logged-in user does not have the role.
>>
>> Appreciate any feedback on this and correct me if I am wrong.
>>
>> [1] - [APIM-3.0] Publisher rest API to check a role name existence
>>
>> Thanks & Regards,
>> *S.Meruja* |Software Engineer | WSO2 Inc.
>> (m) +94779650506 | Email: mer...@wso2.com
>> Linkedin:   https://www.linkedin.com/in/meruja
>> 
>> Medium: https://medium.com/@meruja
>> 
>> ___
>> 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
>


-- 
Best Regards,

*  Shammi Jayasinghe*


*Associate Director/ Architect*
*WSO2, Inc.*
*+1-812-391-7730*
*+1-812-327-3505*

*http://shammijayasinghe.blogspot.com
*
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] [APIM] Admin REST API to check user role existence

[Frank Leymann]

Dear Meruja,

the URI of the second API (i.e.  /me/roles/{roleName}) is really debatable:
the intent of the */me* part of the URI seems to be to identify the
logged-in user, and to me, such a user is a resource. I.e I assume that a
user is represented in APIM as a resource (but I didn't check the current
API), or has a unique UserID - correct?

Thus, the URI of the API should be something like
.../users/{UserID}?{roleName}  or  /roles/{roleName}?{UserID}.

Best regards,
Frank




Am Di., 5. Mai 2020 um 06:17 Uhr schrieb Meruja Selvamanikkam <
mer...@wso2.com>:

> Hi All,
>
> We are planning to add a REST API endpoint to APIM 3.2.0 Admin Rest APIs
> and the intention is to check the existence of a particular role name (
> Internal/subscriber) when transferring ownership of an application to a
> user. We have similar API in the publisher to check the availability of
> the role[1].
> We have to decide the OAuth2 scope which functionalities are used by Admin
> .
>
> The swagger definition for the new endpoint would be as follows:
>
> ##
> # The Role Name Existence
> ##
>   /roles/{roleName}:
> #-
> # The role name existence check resource
> #-
> head:
>   security:
> - OAuth2Security:
> - apim:
>   summary:
> Check given role name already exists
>   description:
> Using this operation, to check whether given role already exists
>   parameters:
> - $ref : '#/parameters/roleName'
>   responses:
> 200:
>   description:
> OK.
> Requested role name is returned.
> 404:
>   description:
> Not Found.
> Requested role name does not exist.
>
> ##
> # The Role Name Existence for the logged-in user
> ##
>   /me/roles/{roleName}:
> #-
> # Validate role against a user
> #-
> head:
>   security:
> - OAuth2Security:
> - apim:
>   summary:
> Validate whether the logged-in user has the given role
>   description:
> Using this operation, logged-in user can check whether he has given 
> role.
>   parameters:
> - $ref : '#/parameters/roleName'
>   responses:
> 200:
>   description:
> OK.
> Logged-in user has the role.
> 404:
>   description:
> Not Found.
> Logged-in user does not have the role.
>
> Appreciate any feedback on this and correct me if I am wrong.
>
> [1] - [APIM-3.0] Publisher rest API to check a role name existence
>
> Thanks & Regards,
> *S.Meruja* |Software Engineer | WSO2 Inc.
> (m) +94779650506 | Email: mer...@wso2.com
> Linkedin:   https://www.linkedin.com/in/meruja
> 
> Medium: https://medium.com/@meruja
> 
> ___
> 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

Re: [Architecture] [APIM] Admin REST API to check user role existence

[Thilini Shanika]

On Tue, May 5, 2020 at 11:36 AM Vithursa Mahendrarajah 
wrote:

> Hi Meruja,
>
> The Publisher REST APIs for role validation is used to check whether the given
> role exists and the logged-in user has the given role. Here the role is
> taken from the user input, AFAIU the requirement, in this case we need to
> check whether the new user has the subscriber role before changing the
> application owner. Please correct if it is wrong.
>
> Since we need to validate whether the user has only a particular role, we
> do not need to have roleId in the resource path. Shall we have a resource
> name like /user/validate-subscriber-role. WDYT?
>
IMO, we shouldn't restrict the API for subscriber user validation only and
it's better to keep it as a generic API which we can reuse in cases of role
validations in future requirements as well(if any).

>
> Thanks,
> Vithursa
>
>
> On Tue, May 5, 2020 at 9:47 AM Meruja Selvamanikkam 
> wrote:
>
>> Hi All,
>>
>> We are planning to add a REST API endpoint to APIM 3.2.0 Admin Rest APIs
>> and the intention is to check the existence of a particular role name (
>> Internal/subscriber) when transferring ownership of an application to a
>> user. We have similar API in the publisher to check the availability of
>> the role[1].
>> We have to decide the OAuth2 scope which functionalities are used by Admin
>> .
>>
>> The swagger definition for the new endpoint would be as follows:
>>
>> ##
>> # The Role Name Existence
>> ##
>>   /roles/{roleName}:
>> #-
>> # The role name existence check resource
>> #-
>> head:
>>   security:
>> - OAuth2Security:
>> - apim:
>>   summary:
>> Check given role name already exists
>>   description:
>> Using this operation, to check whether given role already exists
>>   parameters:
>> - $ref : '#/parameters/roleName'
>>   responses:
>> 200:
>>   description:
>> OK.
>> Requested role name is returned.
>> 404:
>>   description:
>> Not Found.
>> Requested role name does not exist.
>>
>> ##
>> # The Role Name Existence for the logged-in user
>> ##
>>   /me/roles/{roleName}:
>> #-
>> # Validate role against a user
>> #-
>> head:
>>   security:
>> - OAuth2Security:
>> - apim:
>>   summary:
>> Validate whether the logged-in user has the given role
>>   description:
>> Using this operation, logged-in user can check whether he has given 
>> role.
>>   parameters:
>> - $ref : '#/parameters/roleName'
>>   responses:
>> 200:
>>   description:
>> OK.
>> Logged-in user has the role.
>> 404:
>>   description:
>> Not Found.
>> Logged-in user does not have the role.
>>
>> Appreciate any feedback on this and correct me if I am wrong.
>>
>> [1] - [APIM-3.0] Publisher rest API to check a role name existence
>>
>> Thanks & Regards,
>> *S.Meruja* |Software Engineer | WSO2 Inc.
>> (m) +94779650506 | Email: mer...@wso2.com
>> Linkedin:   https://www.linkedin.com/in/meruja
>> 
>> Medium: https://medium.com/@meruja
>> 
>> ___
>> Architecture mailing list
>> Architecture@wso2.org
>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>
>
>
> --
> *Vithursa Mahendrarajah* | Senior Software Engineer | WSO2 Inc
> (m) +94 766 695 643 | (e) vithu...@wso2.com
>
> * [image: https://wso2.com/signature]
> *
>


-- 
Thilini Shanika
Technical Lead
WSO2, Inc.; http://wso2.com
20, Palmgrove Avenue, Colombo 3
Mobile: +94710892258
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] [APIM] Admin REST API to check user role existence

[Vithursa Mahendrarajah]

Hi Meruja,

The Publisher REST APIs for role validation is used to check whether the given
role exists and the logged-in user has the given role. Here the role is
taken from the user input, AFAIU the requirement, in this case we need to
check whether the new user has the subscriber role before changing the
application owner. Please correct if it is wrong.

Since we need to validate whether the user has only a particular role, we
do not need to have roleId in the resource path. Shall we have a resource
name like /user/validate-subscriber-role. WDYT?

Thanks,
Vithursa


On Tue, May 5, 2020 at 9:47 AM Meruja Selvamanikkam  wrote:

> Hi All,
>
> We are planning to add a REST API endpoint to APIM 3.2.0 Admin Rest APIs
> and the intention is to check the existence of a particular role name (
> Internal/subscriber) when transferring ownership of an application to a
> user. We have similar API in the publisher to check the availability of
> the role[1].
> We have to decide the OAuth2 scope which functionalities are used by Admin
> .
>
> The swagger definition for the new endpoint would be as follows:
>
> ##
> # The Role Name Existence
> ##
>   /roles/{roleName}:
> #-
> # The role name existence check resource
> #-
> head:
>   security:
> - OAuth2Security:
> - apim:
>   summary:
> Check given role name already exists
>   description:
> Using this operation, to check whether given role already exists
>   parameters:
> - $ref : '#/parameters/roleName'
>   responses:
> 200:
>   description:
> OK.
> Requested role name is returned.
> 404:
>   description:
> Not Found.
> Requested role name does not exist.
>
> ##
> # The Role Name Existence for the logged-in user
> ##
>   /me/roles/{roleName}:
> #-
> # Validate role against a user
> #-
> head:
>   security:
> - OAuth2Security:
> - apim:
>   summary:
> Validate whether the logged-in user has the given role
>   description:
> Using this operation, logged-in user can check whether he has given 
> role.
>   parameters:
> - $ref : '#/parameters/roleName'
>   responses:
> 200:
>   description:
> OK.
> Logged-in user has the role.
> 404:
>   description:
> Not Found.
> Logged-in user does not have the role.
>
> Appreciate any feedback on this and correct me if I am wrong.
>
> [1] - [APIM-3.0] Publisher rest API to check a role name existence
>
> Thanks & Regards,
> *S.Meruja* |Software Engineer | WSO2 Inc.
> (m) +94779650506 | Email: mer...@wso2.com
> Linkedin:   https://www.linkedin.com/in/meruja
> 
> Medium: https://medium.com/@meruja
> 
> ___
> Architecture mailing list
> Architecture@wso2.org
> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>


-- 
*Vithursa Mahendrarajah* | Senior Software Engineer | WSO2 Inc
(m) +94 766 695 643 | (e) vithu...@wso2.com

* [image: https://wso2.com/signature]
*
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

[Architecture] [APIM] Admin REST API to check user role existence

[Meruja Selvamanikkam]

Hi All,

We are planning to add a REST API endpoint to APIM 3.2.0 Admin Rest APIs
and the intention is to check the existence of a particular role name (
Internal/subscriber) when transferring ownership of an application to a
user. We have similar API in the publisher to check the availability of the
role[1].
We have to decide the OAuth2 scope which functionalities are used by Admin.

The swagger definition for the new endpoint would be as follows:

##
# The Role Name Existence
##
  /roles/{roleName}:
#-
# The role name existence check resource
#-
head:
  security:
- OAuth2Security:
- apim:
  summary:
Check given role name already exists
  description:
Using this operation, to check whether given role already exists
  parameters:
- $ref : '#/parameters/roleName'
  responses:
200:
  description:
OK.
Requested role name is returned.
404:
  description:
Not Found.
Requested role name does not exist.

##
# The Role Name Existence for the logged-in user
##
  /me/roles/{roleName}:
#-
# Validate role against a user
#-
head:
  security:
- OAuth2Security:
- apim:
  summary:
Validate whether the logged-in user has the given role
  description:
Using this operation, logged-in user can check whether he has
given role.
  parameters:
- $ref : '#/parameters/roleName'
  responses:
200:
  description:
OK.
Logged-in user has the role.
404:
  description:
Not Found.
Logged-in user does not have the role.

Appreciate any feedback on this and correct me if I am wrong.

[1] - [APIM-3.0] Publisher rest API to check a role name existence

Thanks & Regards,
*S.Meruja* |Software Engineer | WSO2 Inc.
(m) +94779650506 | Email: mer...@wso2.com
Linkedin:   https://www.linkedin.com/in/meruja

Medium: https://medium.com/@meruja

___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture