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
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
