Hi Sumedha,

Thank you very mush for your detailed explanation. I will look into this.

Thanks,
Geesara

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.
> 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
>



-- 
Geesara Prathap Kulathunga
Software Engineer
WSO2 Inc; http://wso2.com
Mobile : +940772684174
_______________________________________________
Architecture mailing list
[email protected]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Reply via email to