Hi Prabath, Sorry I missed the mail, yes it would be great if we can talk about this further.
On Tue, Sep 22, 2015 at 1:54 AM, Prabath Siriwardena <[email protected]> wrote: > Having a direct connection with IS is not mandatory... > > The Trusted IdP is a proxy - a representation of the external Identity > Provider, in DSS itself... > > Thanks & regards, > -Prabath > > > On Mon, Sep 21, 2015 at 1:19 PM, Nuwan Bandara <[email protected]> wrote: > >> >> >> 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). >>> >> In current implementation(which I have suggested above) there is no need to enable UT, because entire message context is passed to the extension point where user can extract request headers and use them, So for example, if we invoke DSS with "X-JWT-Assertion" in the header, we can use the extension point to extract roles from the jwt. >>> 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. >>> >> For the second point where user may need to get all the roles he can see(to configure data service) he can point to a third party IDP as you have mentioned and retrieve the roles from that, For that we passed the tenant id of the current user to the method. So whoever implement a extension point can use that info to filter out roles from the third party IDP as well. I guess I understood you correctly, But it's better if we can have a discussion 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
