On Mon, Sep 21, 2015 at 2:31 PM, Prabath Siriwardena <[email protected]> wrote:
> If I understand your requirement correctly, this is about a federation > scenario, where users are not under the domain of DSS. > > I guess we need to fix couple of things here.. > > When I last looked into DSS - the way the DSS picks the username is from > the UT header - and the DS must be secured with UT to enable RBAC (please > correct me if not). > > There we need to introduce an extension point to provide the username as > well as the roles of the user. And out-of-the-box we can ship UT based > handler (please check how its done in Entitlement mediator in ESB). > > With that way, irrespective of the the security context, you can find the > user and the roles. > > The above scenario is not just for federation - but for both scenarios. > > Now - how do we have handle this in a federation scenario - I guess that > is what you try to fix here. > > The runtime behavior won't change from what is described above, even in > the federation case. You pass the security context to the extension and get > back username and the roles, and security context will carry user's roles. > > Now the challenge is at the configuration time. How do find the allowed > roles, in a federation case..? > > This is why we have trusted identity provider feature. In a federation > scenario, you first need to add a trusted identity provider. Each trusted > identity provider defines its own roles - and in DSS wizard you pick the > IdP and the roles associated with it. > When we add IS as a trusted IDP, at design time DSS will call IS and get all the roles so we can pic a set to secure the DSS ? Is that correct ? Regards, /Nuwan > > Please let me know if you would like to discuss further on this.. > > Thanks & regards, > -Prabath > > > On Fri, Sep 18, 2015 at 6:17 AM, Rajith Vitharana <[email protected]> > wrote: > >> Hi, >> >> We are thinking of doing an improvement in role based filtering >> functionality in DSS. We had a scenario where in a clustered environment >> users are only maintained in Wso2 IS. So when trying to do role based >> filtering, DSS tries to find the user in local userstore which doesn't have >> the user which results in error. >> >> So the idea is to provide a extension point where we can configure the >> way to get roles of user. >> >> And when creating data service, we can select the roles which are allowed >> to view filtered content. So for that also we need an api where we can get >> all available user roles. So we'll have two method APIs in a single >> interface as follows >> >> [1] - public String[] getUserRoles(MessageContext msgContext) throws >> DataServiceFault >> [2] - public String[] getAvailableUserRoles() throws DataServiceFault >> >> [1] and [2] will return array of role names. >> And to configure this extension we are going to provide a config file >> called "dataservices.xml" in "conf" folder >> >> Appreciate your feedback on this. >> >> Thanks, >> >> -- >> Rajith Vitharana >> >> Software Engineer, >> WSO2 Inc. : wso2.com >> Mobile : +94715883223 >> Blog : http://lankavitharana.blogspot.com/ >> >> _______________________________________________ >> Architecture mailing list >> [email protected] >> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >> >> > > > -- > Thanks & Regards, > Prabath > > Twitter : @prabath > LinkedIn : http://www.linkedin.com/in/prabathsiriwardena > > Mobile : +1 650 625 7950 > > http://blog.facilelogin.com > http://blog.api-security.org > > _______________________________________________ > Architecture mailing list > [email protected] > https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture > > -- *Thanks & Regards,* *Nuwan Bandara | Solutions Architect, WSO2 Inc.* *+1 812 606 7390 | +1 650 745 2169 Ext 4212 | http://nuwanbando.com <http://nuwanbando.com> * <http://www.nuwanbando.com/>
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
