Please consider this vote as canceled. We have fixed above issues and done a new release build. We will trigger a new vote thread for 4.1.0-rc2 soon.
Thanks On Wed, Oct 21, 2015 at 12:49 AM, Imesh Gunaratne <im...@wso2.com> wrote: > On Wed, Oct 21, 2015 at 12:22 AM, Akila Ravihansa Perera < > raviha...@wso2.com> wrote: > >> >> Please see inline. Sorry to drag this, but I think it's better to clarify >> unclear areas :) >> > > +1 > >> >>>> Yes that's true but in a such design any other external system will not >>> be able to to access the APIs using API Keys without having to integrate >>> with the same SSO solution. >>> >> >> I tend to disagree. Using a compatible Identity Provider (for eg: WSO2 >> IS) we can secure the API using multiple grant types. In this scenario API >> can be secured via SSO but not limited to that. >> >> AFAIU grant types and API keys are different. API keys can be > pre-generated for a particular user and used in a X system for accessing an > API (Example: EC2 access & secret keys). As long as X system has the API > keys it does not need to talk to an Identity Provider to obtain a token > based on a grant type. > >> >>>> >>> May be this was not clear. We do not need a login page to make a request >>> to an API endpoint which is secured with Basic Auth. We can make a HTTP >>> call with an Authorization header having credentials (Base64 encoded) via >>> HTTPS. >>> >> >> If we are going to send the Authorization header then we need to get the >> credentials from the user first. I'm not clear how you plan to implement >> this without a login screen. How do you propose to create this header in >> client request? >> >> > My concern is that when a system A is talking to a system B where system B > has a dashboard where it talks to its own API, system A does not need to > worry about the API call of system B. System A only needs a way to > authenticate to system B. System B should handle how it authenticate to its > own API. > > In an ideal situation we need to use SSO between system A and B assuming > that the enduser needs to access both systems as a part of a single > solution. However it does not mean that the API of system B should use the > same SSO system for authentication. IMO if the API of system B is generic > and needed by third party systems it should have a more user friendly > authentication system such as API Keys. > >> >>>>> >>>> > Thanks > > On Wed, Oct 21, 2015 at 12:22 AM, Akila Ravihansa Perera < > raviha...@wso2.com> wrote: > >> Hi Imesh, >> >> Please see inline. Sorry to drag this, but I think it's better to clarify >> unclear areas :) >> >> SSO can be used to authenticate the user who is accessing the >>>> monitoring/metering dashboard, thereby authenticating him to the API as >>>> well. We don't need to maintain a session token/cookie for this which is an >>>> overhead for this scenario, IMO. >>>> >>>> >>> Yes that's true but in a such design any other external system will not >>> be able to to access the APIs using API Keys without having to integrate >>> with the same SSO solution. >>> >> >> I tend to disagree. Using a compatible Identity Provider (for eg: WSO2 >> IS) we can secure the API using multiple grant types. In this scenario API >> can be secured via SSO but not limited to that. >> >> >>> Imagine Twitter has exposed set of APIs using Twitter SSO solution. Now >>> if we were to consume those APIs in a X system. This X system needs to >>> integrate with Twitter SSO solution first. IMO this is not a good design, >>> ideally those APIs should be accessible with API Keys. This is how actually >>> Twitter has exposed their APIs. >>> >>>> >>>>> >>>> If we are using basic auth, the user needs to submit the credentials >>>> via a form, which is again an overhead. Any implementation of >>>> authToken/JSESSIONID would require the user to submit credential at some >>>> layer. What I'm suggesting is to authenticate the user via SSO to the DAS >>>> dashboard, which would authenticate him to the API as well. I'm -1 on >>>> developing a separate login screen for this. >>>> >>>> >>> May be this was not clear. We do not need a login page to make a request >>> to an API endpoint which is secured with Basic Auth. We can make a HTTP >>> call with an Authorization header having credentials (Base64 encoded) via >>> HTTPS. >>> >> >> If we are going to send the Authorization header then we need to get the >> credentials from the user first. I'm not clear how you plan to implement >> this without a login screen. How do you propose to create this header in >> client request? >> >> >>> >>>>> >>>> This would not be manageable as we add entities in future I think. We >>>> can handle this internally by not using the request parameter variable to >>>> create the query. But rather choose the correct sql query conditionally >>>> based on the request parameter. This would basically result in rewriting >>>> all Jaggery files. >>>> >>> >> >> >>> >>> Yes ideally it should be the context path (/api/member -> member table, >>> /api/cluster/health -> cluster health table, etc) >>> >> >> +1 >> >> >> >>> >>> Thanks >>> >>> On Tue, Oct 20, 2015 at 11:40 PM, Akila Ravihansa Perera < >>> raviha...@wso2.com> wrote: >>> >>>> Hi Gayan, >>>> >>>> The code reference you pointed at [1] is used in a prepared SQL >>>> statement [2]. The risk of SQL injection attack is minimal in that case, >>>> AFAIU. >>>> >>>> [1] >>>> https://github.com/wso2/product-private-paas/blob/v4.1.0-rc1/extensions/das/artifacts/metering-dashboard/jaggery-files/member-info.jag#L49 >>>> [2] >>>> https://github.com/wso2/product-private-paas/blob/v4.1.0-rc1/extensions/das/artifacts/metering-dashboard/jaggery-files/member-info.jag#L53 >>>> >>>> Thanks. >>>> >>>> On Tue, Oct 20, 2015 at 11:33 PM, Akila Ravihansa Perera < >>>> raviha...@wso2.com> wrote: >>>> >>>>> Hi Imesh, >>>>> >>>>> Please see inline. >>>>> >>>>> On Tue, Oct 20, 2015 at 11:08 PM, Imesh Gunaratne <im...@wso2.com> >>>>> wrote: >>>>> >>>>>> On Tue, Oct 20, 2015 at 10:25 PM, Akila Ravihansa Perera < >>>>>> raviha...@wso2.com> wrote: >>>>>>> >>>>>>> >>>>>>> I think the proper way to secure the Jaggery services is by using >>>>>>> SSO. >>>>>>> >>>>>> >>>>>> I tend to disagree on this statement. SSO is used when authenticating >>>>>> a human to a series of software systems. An API should not use SSO for >>>>>> authentication rather it should use session based authentication either >>>>>> by >>>>>> creating session tokens or API Keys, refer this [3]. >>>>>> >>>>> >>>>> SSO can be used to authenticate the user who is accessing the >>>>> monitoring/metering dashboard, thereby authenticating him to the API as >>>>> well. We don't need to maintain a session token/cookie for this which is >>>>> an >>>>> overhead for this scenario, IMO. >>>>> >>>>> >>>>>> >>>>>> >>>>>>> According to the thread on wso2dev@ with subject "SingleSignOn >>>>>>> support in DAS Analytics Dashboard" this is not yet supported in DAS. >>>>>>> The >>>>>>> approach taken in analytics.jsg as you mentioned require a separate >>>>>>> login >>>>>>> screen as in [1]. IMHO, this is not a suitable method to secure a >>>>>>> Jaggery >>>>>>> based API. >>>>>>> >>>>>>> No, have a look at the analytics.jag authentication logic. It first >>>>>> accepts an Authorization header and creates a session token. >>>>>> Authorization >>>>>> header can accept basic auth, see [4]. Afterwards corresponding calls are >>>>>> authenticated using authToken/JSESSIONID. >>>>>> >>>>> >>>>> If we are using basic auth, the user needs to submit the credentials >>>>> via a form, which is again an overhead. Any implementation of >>>>> authToken/JSESSIONID would require the user to submit credential at some >>>>> layer. What I'm suggesting is to authenticate the user via SSO to the DAS >>>>> dashboard, which would authenticate him to the API as well. I'm -1 on >>>>> developing a separate login screen for this. >>>>> >>>>> >>>>>> >>>>>> >>>>>>> Regarding table names in SQL queries; this is not the best approach >>>>>>> to design the API but these table names are escaped from request >>>>>>> parameters >>>>>>> [2] which would minimize the risk of a SQL injection attack. This is >>>>>>> definitely a potential security issue as well as an API design issue we >>>>>>> need to fix. But I think fixing this will need a major refactoring to >>>>>>> the >>>>>>> Jaggery files. wdyt? >>>>>>> >>>>>> >>>>>> No, we can simply fix this by creating an API per table/entity. >>>>>> >>>>> >>>>> This would not be manageable as we add entities in future I think. We >>>>> can handle this internally by not using the request parameter variable to >>>>> create the query. But rather choose the correct sql query conditionally >>>>> based on the request parameter. This would basically result in rewriting >>>>> all Jaggery files. >>>>> >>>>> Thanks. >>>>> >>>>> >>>>> >>>>>> >>>>>>> [1] >>>>>>> https://github.com/wso2/carbon-dashboards/blob/master/apps/portal/theme/templates/login.jag >>>>>>> [2] >>>>>>> https://github.com/wso2/product-private-paas/blob/v4.1.0-rc1/extensions/das/artifacts/metering-dashboard/jaggery-files/member-info.jag#L26 >>>>>>> >>>>>>> [3] https://www.owasp.org/index.php/REST_Security_Cheat_Sheet >>>>>> [4] >>>>>> https://github.com/wso2/carbon-analytics/blob/d7d4f7c31981eb6aff8921fefba7c030eb11a80a/components/analytics-io/org.wso2.carbon.analytics.jsservice/src/main/java/org/wso2/carbon/analytics/jsservice/Utils.java#L352 >>>>>> >>>>>> Thanks >>>>>> >>>>>> On Tue, Oct 20, 2015 at 10:25 PM, Akila Ravihansa Perera < >>>>>> raviha...@wso2.com> wrote: >>>>>> >>>>>>> Hi Imesh, >>>>>>> >>>>>>> I think the proper way to secure the Jaggery services is by using >>>>>>> SSO. According to the thread on wso2dev@ with subject "SingleSignOn >>>>>>> support in DAS Analytics Dashboard" this is not yet supported in DAS. >>>>>>> The >>>>>>> approach taken in analytics.jsg as you mentioned require a separate >>>>>>> login >>>>>>> screen as in [1]. IMHO, this is not a suitable method to secure a >>>>>>> Jaggery >>>>>>> based API. >>>>>>> >>>>>>> Regarding table names in SQL queries; this is not the best approach >>>>>>> to design the API but these table names are escaped from request >>>>>>> parameters >>>>>>> [2] which would minimize the risk of a SQL injection attack. This is >>>>>>> definitely a potential security issue as well as an API design issue we >>>>>>> need to fix. But I think fixing this will need a major refactoring to >>>>>>> the >>>>>>> Jaggery files. wdyt? >>>>>>> >>>>>>> [1] >>>>>>> https://github.com/wso2/carbon-dashboards/blob/master/apps/portal/theme/templates/login.jag >>>>>>> [2] >>>>>>> https://github.com/wso2/product-private-paas/blob/v4.1.0-rc1/extensions/das/artifacts/metering-dashboard/jaggery-files/member-info.jag#L26 >>>>>>> >>>>>>> Thanks. >>>>>>> >>>>>>> On Tue, Oct 20, 2015 at 8:38 PM, Imesh Gunaratne <im...@wso2.com> >>>>>>> wrote: >>>>>>> >>>>>>>> Hi, >>>>>>>> >>>>>>>> It looks like there are two security issues in the APIs exposed by >>>>>>>> the DAS metering and monitoring dashboards [1], [2]: >>>>>>>> >>>>>>>> - APIs have no authentication mechanism >>>>>>>> - Table name is concatenated in the SQL queries >>>>>>>> >>>>>>>> We may need to add an authentication check similar to analytics.jag >>>>>>>> [3]: >>>>>>>> >>>>>>>> var authParam = request.getHeader(AUTHORIZATION_HEADER); >>>>>>>> if (authParam != null) { >>>>>>>> credentials = JSUtils.authenticate(authParam); >>>>>>>> authenticationAdminStub = new >>>>>>>> AuthenticationAdminStub(authenticationWSUrl); >>>>>>>> authenticationAdminStub.login(credentials[0], >>>>>>>> credentials[1], LOCALHOST); >>>>>>>> var serviceContext = >>>>>>>> authenticationAdminStub._getServiceClient().getLastOperationContext() >>>>>>>> .getServiceContext(); >>>>>>>> var sessionCookie = >>>>>>>> serviceContext.getProperty(HTTPConstants.COOKIE_STRING); >>>>>>>> options.setProperty(HTTPConstants.COOKIE_STRING, >>>>>>>> sessionCookie); >>>>>>>> } else { >>>>>>>> var token = session.get(AUTH_TOKEN); >>>>>>>> if (token != null) { >>>>>>>> options.setProperty(HTTPConstants.COOKIE_STRING, token); >>>>>>>> } else { >>>>>>>> log.error("user is not authenticated!"); >>>>>>>> response.status = HTTP_USER_NOT_AUTHENTICATED; >>>>>>>> print('{ "status": "Failed", "message": "User is not >>>>>>>> authenticated." }'); >>>>>>>> return; >>>>>>>> } >>>>>>>> } >>>>>>>> >>>>>>>> In addition we may need to avoid concatenating table names in SQL >>>>>>>> queries. >>>>>>>> >>>>>>>> [1] >>>>>>>> https://github.com/wso2/product-private-paas/tree/v4.1.0-rc1/extensions/das/artifacts/metering-dashboard/jaggery-files >>>>>>>> [2] >>>>>>>> https://github.com/wso2/product-private-paas/tree/v4.1.0-rc1/extensions/das/artifacts/monitoring-dashboard/jaggery-files >>>>>>>> [3] >>>>>>>> https://github.com/wso2/carbon-dashboards/blob/master/apps/portal/controllers/apis/analytics.jag#L88 >>>>>>>> >>>>>>>> I think we may need to cancel this vote and do RC2 by fixing these >>>>>>>> problems. >>>>>>>> >>>>>>>> Thanks >>>>>>>> >>>>>>>> On Tue, Oct 20, 2015 at 5:02 PM, Akila Ravihansa Perera < >>>>>>>> raviha...@wso2.com> wrote: >>>>>>>> >>>>>>>>> Hi, >>>>>>>>> >>>>>>>>> This is the first release candidate of WSO2 Private PaaS 4.1.0. >>>>>>>>> >>>>>>>>> This release fixes the following issues: >>>>>>>>> https://wso2.org/jira/issues/?filter=12464 >>>>>>>>> >>>>>>>>> Please download, test and vote. The vote will be open for 72 >>>>>>>>> hours or as needed. >>>>>>>>> >>>>>>>>> *​Source and binary distribution files:* >>>>>>>>> https://svn.wso2.org/repos/wso2/scratch/PPAAS/wso2ppaas-4.1.0-rc1 >>>>>>>>> >>>>>>>>> *Maven staging repository:* >>>>>>>>> http://maven.wso2.org/nexus/content/repositories/orgwso2ppaas-027/ >>>>>>>>> >>>>>>>>> *The tag to be voted upon:* >>>>>>>>> https://github.com/wso2/product-private-paas/tree/v4.1.0-rc1 >>>>>>>>> >>>>>>>>> >>>>>>>>> [ ] Broken - do not release (explain why) >>>>>>>>> [ ] Stable - go ahead and release >>>>>>>>> >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> The WSO2 Private PaaS Team >>>>>>>>> >>>>>>>>> _______________________________________________ >>>>>>>>> Dev mailing list >>>>>>>>> Dev@wso2.org >>>>>>>>> http://wso2.org/cgi-bin/mailman/listinfo/dev >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> -- >>>>>>>> *Imesh Gunaratne* >>>>>>>> Senior Technical Lead >>>>>>>> WSO2 Inc: http://wso2.com >>>>>>>> T: +94 11 214 5345 M: +94 77 374 2057 >>>>>>>> W: http://imesh.gunaratne.org >>>>>>>> Lean . Enterprise . Middleware >>>>>>>> >>>>>>>> >>>>>>> >>>>>>> >>>>>>> -- >>>>>>> Akila Ravihansa Perera >>>>>>> WSO2 Inc.; http://wso2.com/ >>>>>>> >>>>>>> Blog: http://ravihansa3000.blogspot.com >>>>>>> >>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> *Imesh Gunaratne* >>>>>> Senior Technical Lead >>>>>> WSO2 Inc: http://wso2.com >>>>>> T: +94 11 214 5345 M: +94 77 374 2057 >>>>>> W: http://imesh.gunaratne.org >>>>>> Lean . Enterprise . Middleware >>>>>> >>>>>> >>>>> >>>>> >>>>> -- >>>>> Akila Ravihansa Perera >>>>> WSO2 Inc.; http://wso2.com/ >>>>> >>>>> Blog: http://ravihansa3000.blogspot.com >>>>> >>>> >>>> >>>> >>>> -- >>>> Akila Ravihansa Perera >>>> WSO2 Inc.; http://wso2.com/ >>>> >>>> Blog: http://ravihansa3000.blogspot.com >>>> >>> >>> >>> >>> -- >>> *Imesh Gunaratne* >>> Senior Technical Lead >>> WSO2 Inc: http://wso2.com >>> T: +94 11 214 5345 M: +94 77 374 2057 >>> W: http://imesh.gunaratne.org >>> Lean . Enterprise . Middleware >>> >>> >> >> >> -- >> Akila Ravihansa Perera >> WSO2 Inc.; http://wso2.com/ >> >> Blog: http://ravihansa3000.blogspot.com >> > > > > -- > *Imesh Gunaratne* > Senior Technical Lead > WSO2 Inc: http://wso2.com > T: +94 11 214 5345 M: +94 77 374 2057 > W: http://imesh.gunaratne.org > Lean . Enterprise . Middleware > > -- *Imesh Gunaratne* Senior Technical Lead WSO2 Inc: http://wso2.com T: +94 11 214 5345 M: +94 77 374 2057 W: http://imesh.gunaratne.org Lean . Enterprise . Middleware
_______________________________________________ Dev mailing list Dev@wso2.org http://wso2.org/cgi-bin/mailman/listinfo/dev
