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