On Mon, Sep 21, 2015 at 8:44 PM, Rajith Vitharana <[email protected]> wrote:
> 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. > > I guess still we would need an extension here. We cannot rely on a specific header parameter... > >>>> 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, > In fact from the IdP - those needs to be these in the security context itself. > 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/ > -- 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
