Hi,

On Mon, Nov 7, 2016 at 2:50 PM, Joseph Fonseka <[email protected]> wrote:

> Hi Ishara
>
> IMO going forward it would be beneficial to stick to swagger standard it
> self to capture scopes in the API Definition. For that we can use a default
> security definition ie. "apim_default".
>
> And if we look at the roles used in scope it is not part of the API
> definition or OAuth it is actually an authorization information for token
> API.
>
+1 Role should not be a part of API definition, But there should be a
mapping between Scope and Roles (may be permissions) and when token issuing
time this scope to Role permission validation shoule be handled.

-Ishara


> As I see we have two options one is to use a vendor extension attribute ie
> "x-scope-roles" and make it a part of API definition or we can use a
> different config to pass that data.
>
> Also I would like to raise another problem that we have which is not being
> able to use the same scope key in two APIs which is somewhat limiting.
>
> Thanks & Regards
> Jo
>
>
>
>
>
>
>
> On Mon, Nov 7, 2016 at 1:53 PM, Malintha Amarasinghe <[email protected]>
> wrote:
>
>> Hi Ishara,
>>
>> On Mon, Nov 7, 2016 at 1:24 PM, Ishara Cooray <[email protected]> wrote:
>>
>>> Hi,
>>>
>>> According to the current APIM 2.0 implementation it supports Swagger
>>> 2.0  yet using the old custom security definition
>>> *x-wso2-security*
>>> Swagger 2.0 we can use a declaration of the security schemes as below.
>>>
>>> api_key:
>>>   type: apiKey
>>>   name: api_key
>>>   in: headerpetstore_auth:
>>>   type: oauth2
>>>   authorizationUrl: http://swagger.io/api/oauth/dialog
>>>   flow: implicit
>>>   scopes:
>>>     write:pets: modify pets in your account
>>>     read:pets: read your pets
>>>
>>> But this *does not have* the support for *roles* as we do in custom
>>> security definition *x-wso2-security *as below.
>>> x-wso2-security:
>>>   apim:
>>>     x-wso2-scopes:
>>>       - description: ""
>>>         roles: admin
>>>         name: apim:api_view
>>>         key: apim:api_view
>>>
>>> According to the current REST API scope validation implementation [1] it
>>> only validates scopes but not roles.
>>>
>> AFAIU we should do role validation at the time a user getting an access
>> token for a particular scope invoking /token API? So at REST API level
>> scope validation will be enough.
>>
>>
>>> So for C5 what could be the definition to supported?
>>>  I think we can drop *x-wso2-security *and stick to Swagger OOTB
>>> support but again there should be a custom way to support roles.
>>>
>>> Or shall we continue to use *x-wso2-security *until Swagger OOTB
>>> support for roles?
>>>
>>> Appreciate your input on this.
>>>
>>>
>>> [1] https://github.com/wso2/carbon-apimgt/blob/master/components
>>> /apimgt/org.wso2.carbon.apimgt.rest.api.util/src/main/java/
>>> org/wso2/carbon/apimgt/rest/api/util/impl/WebAppAuthenticatorImpl.java
>>>
>>> Thanks & Regards,
>>> Ishara Cooray
>>> Senior Software Engineer
>>> Mobile : +9477 262 9512
>>> WSO2, Inc. | http://wso2.com/
>>> Lean . Enterprise . Middleware
>>>
>>> _______________________________________________
>>> Architecture mailing list
>>> [email protected]
>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>>
>>>
>>
>>
>> --
>> Malintha Amarasinghe
>> Software Engineer
>> *WSO2, Inc. - lean | enterprise | middleware*
>> http://wso2.com/
>>
>> Mobile : +94 712383306
>>
>
>
>
> --
>
> --
> *Joseph Fonseka*
> WSO2 Inc.; http://wso2.com
> lean.enterprise.middleware
>
> mobile: +94 772 512 430
> skype: jpfonseka
>
> * <http://lk.linkedin.com/in/rumeshbandara>*
>
>
> _______________________________________________
> Architecture mailing list
> [email protected]
> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>
>


-- 
Ishara Karunarathna
Associate Technical Lead
WSO2 Inc. - lean . enterprise . middleware |  wso2.com

email: [email protected],   blog: isharaaruna.blogspot.com,   mobile:
+94717996791
_______________________________________________
Architecture mailing list
[email protected]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Reply via email to