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