Yes we can safely prevent shared users from regenerating access tokens of
Apps that they are not owners of. This ideally shouldnt be an issue since
Apps should have provision to regenerate a token if required.

On 8 February 2018 at 14:23, Sanjeewa Malalgoda <sanje...@wso2.com> wrote:

> Can shared users generate keys for the application? After first time if
> one user regenerate application access key then it will effect others as we
> revoke and generate application token.
> I think regenerate option and application access token visibility also
> should remove for above shared users. I think generate token with resource
> owner grant by non app owner may cause issues.
>
> Thanks,
> sanjeewa.
>
> On Wed, Feb 7, 2018 at 11:57 AM, Uvindra Dias Jayasinha <uvin...@wso2.com>
> wrote:
>
>> +1 Agreed with Nuwan about how subscriptions should be handled
>>
>>
>> Regarding the behavior of the Admin shared user, seems this is not
>> required because we already have an Admin REST API to change Application
>> ownership available in 2.2.0[1] as discussed in the mail thread[2]. This
>> addresses the requirement of what would happen if an App owner leaves the
>> organization. So we will only address the App Owner and Shared User
>> experience.
>>
>> [1]https://docs.wso2.com/display/AM2xx/apidocs/admin/#!/
>> operations#Application#applicationsApplicationIdChangeOwnerPost
>> [2][C4[]APIM] REST API for changing Owner of a Application
>>
>> On 7 February 2018 at 11:18, Nuwan Dias <nuw...@wso2.com> wrote:
>>
>>>
>>>
>>> On Wed, Feb 7, 2018 at 11:14 AM, Uvindra Dias Jayasinha <
>>> uvin...@wso2.com> wrote:
>>>
>>>> Hi All,
>>>>
>>>> It seems that currently we do not have a clear definition in regarding
>>>> what users can do with shared applications. This has been highlighted in[1]
>>>> and the plan is to address this as part of the APIM 2.2.0 release.
>>>>
>>>> There are two types of users, the *App owner* who creates the App and
>>>> the *shared user* who is able to view the App that is shared with them
>>>> by the App owner.
>>>>
>>>> *Current issues*
>>>> 1. Product allows shared users to attempt updating Apps that are not
>>>> owned by them, which leads to errors because they do not have the required
>>>> permissions.
>>>>
>>>> 2. Product allows shared users to delete Apps that are not owned by
>>>> them which violate the Application ownership concept.
>>>>
>>>> The plan to address this is as follows
>>>>
>>>> *Solution*
>>>> 1. *App Owner *: Has ability to delete/update Apps owned by them.
>>>>
>>>> 2. *Shared user*: Has only Read only access to Apps shared with
>>>> them(cannot delete/update).
>>>> Deletion and updation of Apps will be restricted at API Store UI level.
>>>> App ownership will be   checked before performing App update/delete from
>>>> server side in  order to   enforce this for REST API calls
>>>>
>>>
>>> Shared user needs to view, remove and add subscriptions too IMO.
>>>
>>>>
>>>> 3 *Admin shared user* : Has ability to delete/update Apps shared with
>>>> them. The reason for this is to address practical issues that take place
>>>> when the App owner leaves an organization and there needs to be some way to
>>>> delete/update such an Application.
>>>>
>>>
>>> +1
>>>
>>>>
>>>>
>>>> Please give your feedback on the above.
>>>>
>>>>
>>>> [1] https://github.com/wso2/product-apim/issues/2690
>>>> --
>>>> Regards,
>>>> Uvindra
>>>>
>>>> Mobile: 777733962
>>>>
>>>
>>>
>>>
>>> --
>>> Nuwan Dias
>>>
>>> Software Architect - WSO2, Inc. http://wso2.com
>>> email : nuw...@wso2.com
>>> Phone : +94 777 775 729 <+94%2077%20777%205729>
>>>
>>
>>
>>
>> --
>> Regards,
>> Uvindra
>>
>> Mobile: 777733962
>>
>
>
>
> --
>
> *Sanjeewa Malalgoda*
> WSO2 Inc.
> Mobile : +94713068779 <+94%2071%20306%208779>
>
> <http://sanjeewamalalgoda.blogspot.com/>blog :http://sanjeewamalalgoda.
> blogspot.com/ <http://sanjeewamalalgoda.blogspot.com/>
>
>
>


-- 
Regards,
Uvindra

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

Reply via email to