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?
- 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 <isha...@wso2.com>
wrote:
> HI Sanjeewa, All,
>
> Please find my comment in line.
>
> On Mon, Jan 8, 2018 at 7:43 PM, Sanjeewa Malalgoda <sanje...@wso2.com>
> 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: isha...@wso2.com, blog: isharaaruna.blogspot.com, mobile:
> +94717996791 <+94%2071%20799%206791>
>
>
>
--
Malintha Amarasinghe
*WSO2, Inc. - lean | enterprise | middleware*
http://wso2.com/
Mobile : +94 712383306
_______________________________________________
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
