Authentication mechanism can be different based on the scenario. For an example if we think of API Manager usecase then actual end user will not register scopes on behalf of him. Instead of he will make API creation request and API core will initiate registration flow with scope registration API. So its more like server to server communication in this case. We are anyway thinking about letting users to plug different authentication handlers per API basis. So it will not be a problem.
+1 to have quick meeting to discuss further. Thanks, sanjeewa. 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? > > 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 <071%20238%203306> > -- *Sanjeewa Malalgoda* WSO2 Inc. Mobile : +94713068779 <http://sanjeewamalalgoda.blogspot.com/>blog :http://sanjeewamalalgoda.blogspot.com/ <http://sanjeewamalalgoda.blogspot.com/>
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
