Hi,
The objective has been achieved already by,
- Adding additional property "disabled" for each editable input element
/ or render the element only if adhere to the given condition
- Setting the condition value by considering the user's (token's) scopes
(whether user has apim:api_create/ apim:api_publisher).
We have other condition to consider the update permission; that is the API
LIfeCycle status.
- i.e. if the user is a creator, he cannot update an API which is in
'Published' state.
In general the creator can update APIs only in ‘created’ state. (cannot
update any other states: Prototyped, Blocked, Deprecated, Retired )
Please correct me if this should be different.
So we can define the below function in AUthManager.js.
static *isUpdateRestricted*(scopesAllowedToEdit, api) {
// determines whether the user is a publisher or creator (based on
what is passed from the element)
if (scopesAllowedToEdit.filter(element =>
AuthManager.getUser().scopes.includes(element)).length > 0) {
// if the user has publisher role, no need to consider the api
LifeCycleStatus
if (AuthManager.getUser().scopes.includes('apim:api_publish')) {
return false;
} else if (
// if the user has creator role, but not the publisher role
AuthManager.getUser().scopes.includes('apim:api_create')
&& api.lifeCycleStatus === 'CREATED') {
return false;
} else {
return true;
}
}
return true;
}
Then we may call this function when rendering the React input elements as below.
<TextField
disabled={AuthManager.*isUpdateRestricted*(['apim:api_create',
'apim:api_publish'], api)}
..
/>
So we will have to call this function in each input element in the
Publisher App.
Please raise if there is any concern
Regards,
Samitha
On Mon, Aug 5, 2019 at 5:08 PM Samitha Chathuranga <[email protected]> wrote:
> Hi All,
>
> This is an update on the discussion points and conclusions in the meeting
> we had regarding this.
>
> - Will proceed with the above suggested approach of changing the
> existing PUT api/ resource in REST API. (discussed on using a separate
> PATCH resource, but considering the similar or more additional work
> required with that, it was discarded)
> - We will fail the request if it detects some unauthorized fields are
> going to be updated. 401 Unauthorized error will be returned in that case.
> - Change the fields that are allowed for publisher user to update. So
> those fields are,
> - Visibility on store
> - Tags
> - Docs
> - Subscription availability
> - Subscription tiers
> - Business info
> - Gateways
> - API properties
>
> (Please add if I am missing anything here)
>
> - Publisher new react app shows segments/menu items for each API
> field/artifact group in the left side navigation panel. So there is no
> separate segment for publisher's update-allowed fields. To identify them as
> managed fields, the related sections will be listed under a separate group.
> (may be separated by a horizontal line)
>
> Please add if I have missed anything.
>
> Regards,
> Samitha
>
> On Thu, Aug 1, 2019 at 11:21 AM Harsha Kumara <[email protected]> wrote:
>
>>
>>
>> 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
>>
>
>
> --
> *Samitha Chathuranga*
> *Senior Software Engineer*, *WSO2 Inc.*
> lean.enterprise.middleware
> Mobile: +94715123761
>
> [image: http://wso2.com/signature] <http://wso2.com/signature>
>
--
*Samitha Chathuranga*
*Senior Software Engineer*, *WSO2 Inc.*
lean.enterprise.middleware
Mobile: +94715123761
[image: http://wso2.com/signature] <http://wso2.com/signature>
_______________________________________________
Architecture mailing list
[email protected]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
