Hi Nuwan, Current scope-to-role mapping we do via the API publisher UI. Are you talking about some other functionality?
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 Blog: http://muthulee.blogspot.com Lean . Enterprise . Middleware
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
