On Thu, Aug 1, 2019 at 11:05 AM Samitha Chathuranga <[email protected]>
wrote:

>
>
> On Tue, Jul 30, 2019 at 12:03 PM Malintha Amarasinghe <[email protected]>
> wrote:
>
>>
>>
>> On Tue, Jul 30, 2019 at 11:56 AM Samitha Chathuranga <[email protected]>
>> wrote:
>>
>>> Hi all,
>>>
>>> *Problem:*
>>>
>>> The objective of this task is to allow updating the authorized field of
>>> an API for a particular user through the Publisher REST API, through PUT
>>> /apis/{apiId}. Current behavior is that the
>>> REST API level web app authenticator doesn't allow updating individual
>>> fields considering an individual field's authorization level. If the
>>> user(user's token) doesn't have the apim:api:create
>>> scope (which is defined under /apis/{apiId} PUT resource, in the api
>>> publisher REST API swagger) the REST API level authenticator fails the
>>> request.
>>>
>>> The initiative behind adding this feature is that the new React based
>>> publisher doesn't have a separation of API fields as "Design", "Implement"
>>> and "Manage" as in 2.6.0 and all the
>>> operations are done though Publisher REST API (i.e. no jaggery APIs). As
>>> there are no separation of API fields as "Design", "Implement" and
>>> "Manage", it is not even possible to update
>>> separate sets of fields via separate calls. So the requirement arises
>>> that we need to improve the existing REST api to facilitate updating any
>>> the authorized API fields from all the fields in single call.
>>>
>>> *Solution proposed:*
>>>
>>> The tasks we have to do do address this issue are as below.
>>>
>>>    - In old publisher REST API we had "x-scope" property to define
>>>    scopes and now in new publisher, we use "OAuth2Security"property. In both
>>>    the scenarios, we can define only single
>>>    scope definition per resource. So to solve the above problem, we
>>>    should be able to define multiple scopes per each resource.
>>>
>>>
>>> So the updated API Publisher REST API Swagger definition would be as
>>> below.
>>>
>>> /apis/{apiId}:
>>>   ---
>>>
>>> put:
>>>   x-wso2-curl: "curl -k -H \"Authorization: Bearer ....
>>>   x-wso2-request: "PUT 
>>> https://127.0.0.1:9443/api/am/publisher/v1.0/apis/7a2298c 
>>> <https://127.0.0.1:9443/api/am/publisher/v1.0/apis/7a2298c4-c905-403f-8fac-38c73301631f%5CnAuthorization>....
>>>   x-wso2-response: "HTTP/1.1 200 OK\nContent-Type: 
>>> application/json\n\n{\r\n   \"id\": \"7a2298c4-c905-.....
>>>   security:
>>>     - OAuth2Security:
>>>       - apim:api_create
>>>       - apim:api_publish
>>>
>>>
>>>    -
>>>
>>>    Set the token Info into the CXF message context within 
>>> org.wso2.carbon.apimgt.rest.api.util.impl.WebAppAuthenticatorImpl, so the 
>>> token scopes
>>>    can be validated in API service impl layer.
>>>
>>>    - Define the required specific scope that a user needs to update
>>>    that field, as an annotation on each API field in the APIDTO .
>>>
>>>    @Scope(name = "apim:api_create", description="")
>>>    private String wsdlUri = null;
>>>
>>>    This will decide that an access token should have the scope
>>>    "apim:api_create" to update that field.
>>>    We can set the above annotation in the DTO by defining an additional
>>>    property (i.e. x-allowUpdatesFor: scope:) withinn the API type definition
>>>    in publisher REST API Swagger as
>>>    below and updating the API DTO model template related pojo mustache
>>>    file (server-templates/pojo.mustache)
>>>
>>>    definitions:
>>>
>>>      API:
>>>
>>>    wsdlUri:
>>>      x-allowUpdatesFor:
>>>        scope: apim:api_create
>>>
>>>
>>>
>>>    - So in ApisApiServiceImpl, when an API is going to be updated in
>>>    apisApiIdPut(..) we may resolve the field scopes from the API DTO and 
>>> then
>>>    compare
>>>    with the token's scopes. If the token doesn't have apim:api_create
>>>    scope, then the field value will be overridden by the original (same old)
>>>    value. Else, the passed value from body
>>>    will be set as the new value.
>>>
>>>
>> Should we fail the request if it detects some unallowed fields are
>> updated, or ignore and overwrite and pass the request?
>>
>> Hi all,
>
> Highly appreciate your concerns on this matter. We need to finalize this
> matter to go forward.
>
I think it would be best to arrange a quick meeting on this.

> Thanks!
>>
>> Please share your suggestions on this suggested solution.
>>>
>>> Regards,
>>> Samitha
>>> --
>>> *Samitha Chathuranga*
>>> *Senior Software Engineer*, *WSO2 Inc.*
>>> lean.enterprise.middleware
>>> Mobile: +94715123761
>>>
>>> [image: http://wso2.com/signature] <http://wso2.com/signature>
>>>
>>
>>
>> --
>> Malintha Amarasinghe
>> *WSO2, Inc. - lean | enterprise | middleware*
>> http://wso2.com/
>>
>> Mobile : +94 712383306
>>
>
>
> --
> *Samitha Chathuranga*
> *Senior Software Engineer*, *WSO2 Inc.*
> lean.enterprise.middleware
> Mobile: +94715123761
>
> [image: http://wso2.com/signature] <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
_______________________________________________
Architecture mailing list
[email protected]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Reply via email to