In the case of API Manager, IS is actually bundled by default since it's required for Security of the APIs on the Gateway.
If other products adopt this model, yes they'd need to pack some identity components. On Tue, 10 Jan 2017 at 5:16 pm, Chathura Ekanayake <[email protected]> wrote: > Are we packing identity components with products, if someone prefers not > to use an external authorization server? > > 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. > 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 <+94%2077%20777%205729> > > > > > > _______________________________________________ > > > Architecture mailing list > > > [email protected] > > > https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture > > > > > > > _______________________________________________ > > Architecture mailing list > > [email protected] > > https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture > >
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
