HI Malintha,

On Wed, Jan 10, 2018 at 11:28 AM, Malintha Amarasinghe <[email protected]>
wrote:

> Hi Ishara,
>
> I am wondering whether it is possible to use OAuth to protect this because
> this itself is actually part of OAuth APIs' implementation. Shall we have a
> quick chat about this today/tomorrow?
>
This is more of a system API and you can use OAuth. and its ok to have some
other authentication mechanism as well.
Lets discuss in a meeting.

-Ishara

>
> Thanks!
>
> On Tue, Jan 9, 2018 at 3:18 PM, Ishara Karunarathna <[email protected]>
> wrote:
>
>> Hi Malintha,
>>
>> On Tue, Jan 9, 2018 at 2:19 PM, Malintha Amarasinghe <[email protected]>
>> wrote:
>>
>>> Hi Ishara,
>>>
>>> Thanks for the info.
>>>
>>> So basically we can consider scope name as unique so we can use the same
>>> to represent the scope ID as well.
>>>
>>> @Sanjeewa, +1 to use scope name for below resources:
>>>
>>> GET|PUT|DELETE  /scopes/{name}
>>>
>>> Regarding permissions, I think can use Basic auth with some permission
>>> checks. But the permission check can be different from product to product;
>>> so how about below options?
>>>
>> I don't think that we can use basic auth here. In the authorization
>> server level we need to identify the resource server, hence better to use
>> OAuth for securing this API.
>>
>> -Ishara
>>
>>>
>>>    - Introducing a security interceptor in carbon-auth level and a
>>>    configuration via deployment.yaml
>>>       - For the required APIs from carbon-auth which needs to be
>>>       protected from Basic auth, we can introduce an interceptor which 
>>> reads the
>>>       config which contains permission mapping for all the required 
>>> carbon-auth
>>>       APIs and intercepts requests and applies permission checks.
>>>    - Keeping the security interceptor at the product level so each
>>>    product can implement their own security interceptor.
>>>
>>> Thanks!
>>>
>>>
>>> On Tue, Jan 9, 2018 at 10:31 AM, Ishara Karunarathna <[email protected]>
>>> wrote:
>>>
>>>> HI Sanjeewa, All,
>>>>
>>>> Please find my comment in line.
>>>>
>>>> On Mon, Jan 8, 2018 at 7:43 PM, Sanjeewa Malalgoda <[email protected]>
>>>> wrote:
>>>>
>>>>> Hi All,
>>>>> We are thinking about adding scope registration support to our
>>>>> carbon-auth implementation. For this we will need to have API to
>>>>> add/update/delete/list scopes. When we analyzed current implementation of
>>>>> API its designed to have API name as unique identifier. Or we can use UUID
>>>>> for that to adhere approach we followed for other APIs. But i dont see
>>>>> issue with having name as unique identifier if its unique. Myself and
>>>>> Malintha had quick discussion about scope registration API and came up 
>>>>> with
>>>>> following attached REST API. We have removed name from resource path of
>>>>> existing API.
>>>>>
>>>>
>>>>  An Identity provider can act as the central authorization server for
>>>> multiple resource servers. In that case same Scope can imterprit by
>>>> different resource servers in different manner.
>>>> So scope should be unique with Scope + resource server and each
>>>> combination will couple with a binding
>>>>
>>>>>
>>>>> We need to think about authentication mechanism for this API as API
>>>>> creators will allow to add scopes per API. Also we need to think how 
>>>>> should
>>>>> we handle adding same scope name by different users for different APIs. If
>>>>> one user defined read scope then others may not be able to define same
>>>>> scope.
>>>>>
>>>> In this case I think scope should be unique within the resource server
>>>> where it can have a globel validation rule. And it whould be easy to
>>>> configure with external authorization servers.
>>>>
>>>> -Ishara
>>>>
>>>>>
>>>>> Since identity server team had experiences with this API they can
>>>>> provide suggestions for API and implementation. We will expose this as
>>>>> MSF4J based API from carbon auth run time.
>>>>>
>>>>> Lets use this thread to discuss all aspects of scope registration and
>>>>> finalize implementation.
>>>>>
>>>>> Thanks,
>>>>> sanjeewa.
>>>>> --
>>>>>
>>>>> *Sanjeewa Malalgoda*
>>>>> WSO2 Inc.
>>>>> Mobile : +94713068779 <+94%2071%20306%208779>
>>>>>
>>>>> <http://sanjeewamalalgoda.blogspot.com/>blog
>>>>> :http://sanjeewamalalgoda.blogspot.com/
>>>>> <http://sanjeewamalalgoda.blogspot.com/>
>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>> --
>>>> Ishara Karunarathna
>>>> Technical Lead
>>>> WSO2 Inc. - lean . enterprise . middleware |  wso2.com
>>>>
>>>> email: [email protected],   blog: isharaaruna.blogspot.com,   mobile:
>>>> +94717996791 <+94%2071%20799%206791>
>>>>
>>>>
>>>>
>>>
>>>
>>> --
>>> Malintha Amarasinghe
>>> *WSO2, Inc. - lean | enterprise | middleware*
>>> http://wso2.com/
>>>
>>> Mobile : +94 712383306 <+94%2071%20238%203306>
>>>
>>
>>
>>
>> --
>> Ishara Karunarathna
>> Technical Lead
>> WSO2 Inc. - lean . enterprise . middleware |  wso2.com
>>
>> email: [email protected],   blog: isharaaruna.blogspot.com,   mobile:
>> +94717996791 <+94%2071%20799%206791>
>>
>>
>>
>
>
> --
> Malintha Amarasinghe
> *WSO2, Inc. - lean | enterprise | middleware*
> http://wso2.com/
>
> Mobile : +94 712383306 <+94%2071%20238%203306>
>



-- 
Ishara Karunarathna
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