Hi Prabath, As the discussion I had with you and Johan, I couldn't find any resource about importing user stores, we can share the user store though, but the original use case came, where user stores won't be shared within servers, but maintained in a single server (for example IS) So as you have advised will go ahead with current implementation, and will change, getAllRoles API to not to use tenantID, and as you have suggested will try to implement a sample extension where user can configure a third party IDP to call and get roles. (will try to do it within 3.5.0 release)
Thanks, On Tue, Sep 22, 2015 at 9:55 AM, Prabath Siriwardena <[email protected]> wrote: > > > 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 > -- 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
