Re: [Architecture] Implementing proper security model for dashboard server

[Manuranga Perera]

>
> This part is already there right? or are we talking about a new
>> implementation?
>
>
> Actually in existing implementation token is generated against cookie. It
> is not actually a bearer token just a session id. To generate bearer token
> we have to use SAML grant type.


Just looked at the code, it seems SAML is first exchanged to a cookie and
then the cookie is used. Ya, this seems wrong, we should be able to get
directly via the grant type.

+1 lets fix it.


[1]
https://github.com/wso2/carbon-dashboards/blob/master/apps/portal/modules/saml-to-cookie.js
-- 
With regards,
*Manu*ranga Perera.

phone : 071 7 70 20 50
mail : m...@wso2.com
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] Implementing proper security model for dashboard server

[Sriskandarajah Suhothayan]

On Fri, Apr 29, 2016 at 6:47 AM, Farasath Ahamed  wrote:

> Hi Suho,
>
> Just to be clear, Are we going to use the Password Grant Type in the case
> where SSO is disabled or is it the Client Credentials grant type using the
> client_id and client_secret of the app created?
>
Sorry it should be  Password Grant Type in the case where SSO is disabled.

>
>
> Thanks,
> Farasath Ahamed
> Software Engineer,
> WSO2 Inc.; http://wso2.com
> lean.enterprise.middleware
>
>
> Email: farasa...@wso2.com
> Mobile: +94777603866
> Blog: blog.farazath.com
> Twitter: @farazath619 
>
> On Thu, Apr 28, 2016 at 10:28 PM, Sriskandarajah Suhothayan  > wrote:
>
>> 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.
>>
>> Sorry my bad it should be Password Grant Type!


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 
>> wrote:
>>
>>> Hi Sumedha,
>>>
>>> On Thu, Apr 28, 2016 at 1:58 PM, Sumedha Rubasinghe 
>>> 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 
 wrote:

> *Requirement:*
> *When dashboard retrieving data from some REST APIs which are secured,
> we do require proper security model in plac

Re: [Architecture] Implementing proper security model for dashboard server

[Geesara Prathap]

On Thu, Apr 28, 2016 at 12:58 PM, Sriskandarajah Suhothayan 
 wrote:

> 1. If SSO is enabled, obtaining a token (OAuth2) using SAML Token and
> passing to the backend


This part is already there right? or are we talking about a new
implementation?

Actually in existing implementation token is generated against cookie. It
is not actually a bearer token just a session id. To generate bearer token
we have to use SAML grant type.

On Fri, Apr 29, 2016 at 6:47 AM, Farasath Ahamed  wrote:

> Hi Suho,
>
> Just to be clear, Are we going to use the Password Grant Type in the case
> where SSO is disabled or is it the Client Credentials grant type using the
> client_id and client_secret of the app created?
>
>
> Thanks,
> Farasath Ahamed
> Software Engineer,
> WSO2 Inc.; http://wso2.com
> lean.enterprise.middleware
>
>
> Email: farasa...@wso2.com
> Mobile: +94777603866
> Blog: blog.farazath.com
> Twitter: @farazath619 
>
> On Thu, Apr 28, 2016 at 10:28 PM, Sriskandarajah Suhothayan  > wrote:
>
>> 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 
>> wrote:
>>
>>> Hi Sumedha,
>>>
>>> On Thu, Apr 28, 2016 at 1:58 PM, Sumedha Rubasinghe 
>>> 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
>>>

Re: [Architecture] Implementing proper security model for dashboard server

[Farasath Ahamed]

Hi Suho,

Just to be clear, Are we going to use the Password Grant Type in the case
where SSO is disabled or is it the Client Credentials grant type using the
client_id and client_secret of the app created?


Thanks,
Farasath Ahamed
Software Engineer,
WSO2 Inc.; http://wso2.com
lean.enterprise.middleware


Email: farasa...@wso2.com
Mobile: +94777603866
Blog: blog.farazath.com
Twitter: @farazath619 

On Thu, Apr 28, 2016 at 10:28 PM, Sriskandarajah Suhothayan 
wrote:

> 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 
> wrote:
>
>> Hi Sumedha,
>>
>> On Thu, Apr 28, 2016 at 1:58 PM, Sumedha Rubasinghe 
>> 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 
>>> 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 gadg

Re: [Architecture] Implementing proper security model for dashboard server

[Manuranga Perera]

On Thu, Apr 28, 2016 at 12:58 PM, Sriskandarajah Suhothayan 
wrote:

> 1. If SSO is enabled, obtaining a token (OAuth2) using SAML Token and
> passing to the backend


This part is already there right? or are we talking about a new
implementation?


-- 
With regards,
*Manu*ranga Perera.

phone : 071 7 70 20 50
mail : m...@wso2.com
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] Implementing proper security model for dashboard server

[Sriskandarajah Suhothayan]

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 
wrote:

> Hi Sumedha,
>
> On Thu, Apr 28, 2016 at 1:58 PM, Sumedha Rubasinghe 
> 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 
>> 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

Re: [Architecture] Implementing proper security model for dashboard server

[Sinthuja Ragendran]

Hi Sumedha,

On Thu, Apr 28, 2016 at 1:58 PM, Sumedha Rubasinghe 
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  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
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] Implementing proper security model for dashboard server

[Geesara Prathap]

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 
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  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
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] Implementing proper security model for dashboard server

[Sumedha Rubasinghe]

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  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
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] Implementing proper security model for dashboard server

[Srinath Perera]

Since gadgets are deployed as an artifact, shouldn't this information
defined at the Gadget level?

Have we thought about what kind of technologies we will support for
security? for example, maybe we can support data retrieval using an OAuth
token in addition to basic auth over HTTPS.

--Srinath


On Thu, Apr 28, 2016 at 1:00 AM, Geesara Prathap  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
>
>
> ___
> Architecture mailing list
> Architecture@wso2.org
> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>
>


-- 

Srinath Perera, Ph.D.
   http://people.apache.org/~hemapani/
   http://srinathsview.blogspot.com/
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

[Architecture] Implementing proper security model for dashboard server

[Geesara Prathap]

*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
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture