On Thu, Apr 28, 2016 at 12:58 PM, Sriskandarajah Suhothayan <[email protected]> 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 <[email protected]> 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: [email protected] > Mobile: +94777603866 > Blog: blog.farazath.com > Twitter: @farazath619 <https://twitter.com/farazath619> > > On Thu, Apr 28, 2016 at 10:28 PM, Sriskandarajah Suhothayan <[email protected] > > 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 <[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 >> >> > > _______________________________________________ > Architecture mailing list > [email protected] > https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture > > -- 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
