Hi Nuwan,
Won't there any admin APIs (REST) exposed by the kernel? In that case, how a product supposed to merge the product API and Kernel API? On Mon, Jan 16, 2017 at 12:05 PM, Nuwan Dias <[email protected]> wrote: > > > On Mon, Jan 16, 2017 at 11:31 AM, Dimuthu Leelarathne <[email protected]> > wrote: > >> Hi Nuwan, >> >> Current scope-to-role mapping we do via the API publisher UI. Are you >> talking about some other functionality? >> > > Yes, this is for C5 product APIs (admin services in C5). Not for the APIs > you create using the API Publisher. > >> >> thanks, >> Dimuthu >> >> >> On Mon, Jan 16, 2017 at 10:48 AM, Nuwan Dias <[email protected]> wrote: >> >>> Hi Dimuthu, >>> >>> On Mon, Jan 16, 2017 at 10:16 AM, Dimuthu Leelarathne <[email protected] >>> > wrote: >>> >>>> Hi Nuwan, >>>> >>>> On Tue, Jan 10, 2017 at 4:48 PM, Nuwan Dias <[email protected]> wrote: >>>> >>>>> Hi, >>>>> >>>>> Since we're moving away from SOAP based admin services to REST APIs >>>>> for Product APIs we need to come to an agreement on the Security >>>>> (Authentication and Authorization) model for the products. >>>>> >>>>> The first question is whether its necessary that all 5 products have a >>>>> common security model? My personal opinion on this is "not necessarily" :) >>>>> since I don't think its common to have 1 general client/tool for >>>>> administering several WSO2 products at once. This question is up for >>>>> debate >>>>> however. >>>>> >>>>> In the case of API Manager we've opted for OAuth2.0 based security for >>>>> both authentication and authorization for the product APIs. The decision >>>>> was taken some time back (when designing the product APIs itself). In >>>>> summary, there are three main motivations for the decision. >>>>> >>>>> 1. OAuth2.0 is established as the standard for REST security (we >>>>> ourselves preach that). >>>>> 2. Since OAuth2.0 is a specification (not tied to an implementation as >>>>> such), anyone who understands HTTP, REST and OAuth can develop a client >>>>> (UI) for the product easily. >>>>> 3. The product can work with any IDP that supports OAuth2.0 (not >>>>> married to WSO2 IS or Carbon). >>>>> >>>>> Since Product APIs on C5 will be on MSF4J, we plan to use two >>>>> interceptors for Authentication and Authorization. Following is the flow >>>>> of >>>>> events for obtaining an access token. >>>>> >>>>> 1. The client (UI) requests the authorization server for an access >>>>> token for a set of scopes by providing it some credentials. The client >>>>> needs to use a suitable OAuth2.0 grant type depending on the application >>>>> type. >>>>> 2. The authorization server validates the credentials. >>>>> 3. The authorization server validates the requested scopes against the >>>>> requesting user. In the case of WSO2 IS, there needs to be a scope-to-role >>>>> mapping (preferably in a config file) on the authorization server so that >>>>> it can validate the user's roles/groups. >>>>> >>>> >>>> Current IS has XACML for scope-to-role mapping for fine grain >>>> authorizations. Isn't it an option for APIM to create scope-to-role mapping >>>> using the existing WSO2IS API? >>>> >>> >>> The scope-to-role mapping is a dev-ops thing since these are specified >>> when one is setting up a deployment. Therefore it should be scriptable. >>> Hence the importance of having it in a config file. >>> >>>> >>>> thanks, >>>> Dimuthu >>>> >>>> >>>>> 4. The authorization server issues an access token bearing the scopes >>>>> for which the user has access to. >>>>> >>>>> *Authentication* >>>>> >>>>> 1. The client (UI) uses the access token in subsequent API calls to >>>>> the Resource Server (MS4FJ). >>>>> 2. The Authentication interceptor will validate the token via the >>>>> /introspect endpoint on the authorization server (IS). >>>>> 3. If the token is valid, the token details (expiry time, scopes, etc) >>>>> are cached on the Resource Server and the request will be handed over to >>>>> the next interceptor. >>>>> >>>>> *Authorization* >>>>> >>>>> 1. The Resource Server maintains a list of (Resource + Action) to >>>>> Scope mappings in a configuration file. Ex: for GET /apis, the required >>>>> scope is "apim:list_apis". >>>>> 2. The Authorization interceptor checks whether the access token bears >>>>> the required scope for the particular action on the resource by reading >>>>> the >>>>> configuration file. >>>>> 3. If the authorization check passes, the request is allowed to >>>>> passthrough. >>>>> >>>>> We need to evaluate whether the same approach is viable for providing >>>>> security for the Product APIs of the rest of the platform. Since security >>>>> is handled via MSF4J interceptors once can technically replace them and >>>>> use >>>>> whatever is best, but we however need to decide whether the above is good >>>>> enough for the platform as the default. >>>>> >>>>> Thanks, >>>>> NuwanD. >>>>> >>>>> -- >>>>> Nuwan Dias >>>>> >>>>> Software Architect - WSO2, Inc. http://wso2.com >>>>> email : [email protected] >>>>> Phone : +94 777 775 729 <077%20777%205729> >>>>> >>>>> _______________________________________________ >>>>> Architecture mailing list >>>>> [email protected] >>>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>>>> >>>>> >>>> >>>> >>>> -- >>>> Dimuthu Leelarathne >>>> Director, Solutions Architecture >>>> >>>> WSO2, Inc. (http://wso2.com) >>>> email: [email protected] >>>> Mobile: +94773661935 <+94%2077%20366%201935> >>>> Blog: http://muthulee.blogspot.com >>>> >>>> Lean . Enterprise . Middleware >>>> >>>> _______________________________________________ >>>> Architecture mailing list >>>> [email protected] >>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>>> >>>> >>> >>> >>> -- >>> Nuwan Dias >>> >>> Software Architect - WSO2, Inc. http://wso2.com >>> email : [email protected] >>> Phone : +94 777 775 729 <077%20777%205729> >>> >>> _______________________________________________ >>> Architecture mailing list >>> [email protected] >>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>> >>> >> >> >> -- >> Dimuthu Leelarathne >> Director, Solutions Architecture >> >> WSO2, Inc. (http://wso2.com) >> email: [email protected] >> Mobile: +94773661935 <+94%2077%20366%201935> >> Blog: http://muthulee.blogspot.com >> >> Lean . Enterprise . Middleware >> >> _______________________________________________ >> Architecture mailing list >> [email protected] >> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >> >> > > > -- > Nuwan Dias > > Software Architect - WSO2, Inc. http://wso2.com > email : [email protected] > Phone : +94 777 775 729 <+94%2077%20777%205729> > > _______________________________________________ > Architecture mailing list > [email protected] > https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture > > -- Thanks Abimaran Kugathasan Senior Software Engineer - API Technologies Email : [email protected] Mobile : +94 773922820 <http://stackoverflow.com/users/515034> <http://lk.linkedin.com/in/abimaran> <http://www.lkabimaran.blogspot.com/> <https://github.com/abimarank> <https://twitter.com/abimaran>
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
