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? 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 Blog: http://muthulee.blogspot.com Lean . Enterprise . Middleware
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
