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