Thanks Sumedha for the points, to make life easy for the gadget developer we decided to add oAuth token retrieval to DS.
Based on the offline discussion with Johann, Sinthuja and Geesara we decided to support only the following scenarios for DS 1. If SSO is enabled, obtaining a token (OAuth2) using SAML Token and passing to the backend 2. If SSO is disabled, obtaining a token (OAuth2) using client credential grant type and passing to the backend, Here the username and password will be obtained at server login and the token is generated at the same time. In both cases we will be using DCR for client registration at the server level, and same token will be used by all gadgets to access the secured backend APIs. To access secured backend from the gadgets a oAuth2Client js service (shindig features) will be implemented at DS, such that gadgets can talk to backend using the oAuth2Client which will embed appropriate authorisation header when sending. Regards Suho On Thu, Apr 28, 2016 at 2:37 PM, Sinthuja Ragendran <[email protected]> wrote: > Hi Sumedha, > > On Thu, Apr 28, 2016 at 1:58 PM, Sumedha Rubasinghe <[email protected]> > wrote: > >> Geesara, >> This is a model that should be coming out of Dashboard perspective. >> >> If we take a look @ basic building blocks of DS, its (similar to what you >> have mentioned) >> - Gadget >> - Dashboard >> - Wizards >> - Dashboard Admin panel >> - etc >> >> Each of these elements should have a permission model associated per >> instance. >> > > Yeah +1, as per now the permission checks are not implemented for these > operations, but we need to incorporate that as well. > > >> For example, defining "permission to view any gadget" is not enough. But >> rather it should be "permission to view Gadget X". >> Same should be extended for all other building blocks. (AFAIK, this is >> not there for gadgets as of now) >> >> These need to be stored @ gadget server level and evaluated b4 rendering >> any gadget. >> > > Yeah, actually we are planning to implement the role based access control > for gadgets and then again different views of the dashboard page based on > roles. > > >> >> Permissions to BE >> ================ >> Once presentation layer permissions are sorted, it becomes responsibility >> of Gadget / Dashboard author to figure out mapping >> those permissions to a backend API. >> >> There are multiple ways to do this based on how backend is secured. >> - Passing session cookie obtained @ login to backend >> - Obtaining a token (OAuth2) using session cooking (using an OAuth2 grant >> type) >> - If SSO is enabled, obtaining a token (OAuth2) using SAML Token >> - IdP enabled deployment >> >> Ensuring backend API's permission requirements match front end user's >> privileges is part of author's >> responsibility. This is not something DS product needs to worry about. >> > > Exactly, but I think there should be some API provided by DS server > (shindig features), so that the users can just call the necessary methods > with respective parameters to get oauth token. WDYT? > > Thanks, > Sinthuja. > > >> If by any chance backend is written using WSO2 technologies, we can >> leverage concepts like >> - Sharing same identity provider for both DS and BE server >> - passing authorisation details from FE to BE using JWT/SAML Response / >> User profile >> >> >> Permissions when gadgets being embedded into other products without >> dashboard >> ================================================================ >> This is yet another perspective of the same problem. This also can be >> solved if we follow same principles >> mentioned above. >> - Having gadget instance level permission definition >> - Way to obtain a gadget by passing in authorisation details (using one >> of the methods mentions above) >> > >> Same applies for dashboards. >> >> >> On Thu, Apr 28, 2016 at 1:00 AM, Geesara Prathap <[email protected]> >> wrote: >> >>> *Requirement:* >>> *When dashboard retrieving data from some REST APIs which are secured, >>> we do require proper security model in place in order to identify who can >>> access this dashboard and at which level should it be done. In addition,how >>> can dashboard be going to communicate with respective REST API securely?* >>> >>> >>> >>> Figure 01: >>> Dashboard Server >>> >>> >>> Data providers for gadgets need to communicate with DS securely. Most of >>> the cases data providers are some REST APIs. There might be a situation >>> which dashboard will be getting data from different data providers as well. >>> In the DS perspective, there must be an effective way to tackle these >>> security related issues up to some extent. Referring to figure 1, we are >>> having three places where we can address these issues. >>> >>> - gadget level >>> - per-dashboard level >>> - dashboard server level >>> >>> What would be the proper place which we can address security concerns in >>> a proper manner? If we try to address this at gadget level, It will be too >>> mush of granularity which may be preventing the acceptable performance of >>> data retrieval from data providers as well as too mush of load to DS >>> itself. Also having problems user authentication and authorization at this >>> level as well as per dashboard level. Dashboard server level would be the >>> ideal place which we can address all those security concerns in a >>> conventional manner. Any advice and suggestions will be greatly appreciated >>> regarding this. >>> >>> Thanks, >>> Geesara, >>> >>> -- >>> Geesara Prathap Kulathunga >>> Software Engineer >>> WSO2 Inc; http://wso2.com >>> Mobile : +940772684174 >>> >>> >> >> >> -- >> /sumedha >> m: +94 773017743 >> b : bit.ly/sumedha >> > > > > -- > *Sinthuja Rajendran* > Associate Technical Lead > WSO2, Inc.:http://wso2.com > > Blog: http://sinthu-rajan.blogspot.com/ > Mobile: +94774273955 > > > -- *S. Suhothayan* Technical Lead & Team Lead of WSO2 Complex Event Processor *WSO2 Inc. *http://wso2.com * <http://wso2.com/>* lean . enterprise . middleware *cell: (+94) 779 756 757 <%28%2B94%29%20779%20756%20757> | blog: http://suhothayan.blogspot.com/ <http://suhothayan.blogspot.com/>twitter: http://twitter.com/suhothayan <http://twitter.com/suhothayan> | linked-in: http://lk.linkedin.com/in/suhothayan <http://lk.linkedin.com/in/suhothayan>*
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
