On Tue, Oct 13, 2015 at 7:45 PM, Sanjeewa Malalgoda <[email protected]> wrote:
> Hi All, > We are working on complete REST complaint API for API Management > operations in product. > We have already discussed about design and implementation details in > architecture mail list. > Now we need to finalize security model for this web service. > > *Problem* > We are exposing API Manager REST API as JAX-RS service. It is having > complex resource paths for different operations(see [1]). > In real production systems these permissions should be able to manage in > extensible manner. > Also we should be able to easily add /update permissions per operations > and associated users/roles etc. > As an example we can consider, > > - API update/edit can be performed only by special user with API > create update permission. > - And API life cycle state change should be done with a user who is > having API publish permission. > - And tier edit/update should be perform by users with administrative > privileges. > > So far we have managed this with permission/role based model. > In addition to that we realized that users having different complex > requirements on permission control(Ex: tier management allow only special > one user, API delete allow to only one specific user etc). > > *Suggested Solution* > As a solution for this we are planning to use XACML permission validation > per invocation. > As of now Jo/Malintha implemented basic authentication based > authentication mechanism. > If we are going for XACML based fine grained permission validation then we > can place XACML handler after authentication handler and do it there. > > *Initial Work* > As initial implementation we quickly implemented CXF interceptor which was > engaged in pre invoke phase and retrieve user name, resource path, > operation(HTTP Method) properties. > Have you guys try to use XACML interceptor comes with CXF OOTB before write our own interceptor ? [1] - http://cxf.apache.org/javadoc/latest-3.0.x/org/apache/cxf/rt/security/xacml/AbstractXACMLAuthorizingInterceptor.html Thanks ! > Then we validated them against already created XACML policy. > If action is permitted then only we will let user to invoke operation, > else he will get permission error saying he doesn't have right permission. > For the initial implementation we used WS entitlement service and in > future we can support thrift server as well. > > *Questions* > For this we need to pack XACML ui features in API Manager. > Otherwise we can make permission validation optional. And if users need it > we can ask them to install XACML features and configure web app to route > requests through XACML validation handler(what we already implemented). > What would be the best approach for this? If we install features it may > cause to increase size of pack. > > Then is it good idea to check permissions per request? If need we can > consider validation information cache at web app side(as per offline chat > with asela it seems there is a cache at service side also) > . > What are the other issues and improvements you see in this approach? > Appreciate your suggestions on this. > > [1]http://hevayo.github.io/restful-apim/#/ > > > Thanks, > sanjeewa. > > > -- > > *Sanjeewa Malalgoda* > WSO2 Inc. > Mobile : +94713068779 > > <http://sanjeewamalalgoda.blogspot.com/>blog > :http://sanjeewamalalgoda.blogspot.com/ > <http://sanjeewamalalgoda.blogspot.com/> > > > > _______________________________________________ > Architecture mailing list > [email protected] > https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture > > -- Sagara Gunathunga Architect; WSO2, Inc.; http://wso2.com V.P Apache Web Services; http://ws.apache.org/ Linkedin; http://www.linkedin.com/in/ssagara Blog ; http://ssagara.blogspot.com
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
