On Tue, Mar 7, 2017 at 12:49 PM, Gayan Gunawardana <[email protected]> wrote:
> > > On Tue, Mar 7, 2017 at 9:43 AM, Ishara Karunarathna <[email protected]> > wrote: > >> Hi, >> >> In SCIM domain is used to represent the whole administrative provisioning >> system . So I don't think domain discuss in the spec directly map to the >> domain concept we have. >> > We are not discussing here provisioning system (domain) concept in the > spec. If name 'domain' is not suitable we can use better name to represent > user store domains. > I think what I said was not clear to you. Since there is a domain concept in the spec using domain name will confused people. So better if we can use name for this. > >> In the spec when defining the tenants they have the option to use tenant >> domain as a path parameter or sub domain. >> >> A URL prefix: "https://www.example.com/Tenants/{tenant_id}/v2/Users";. >> A sub-domain: "https://{tenant_id}.example.com/v2/Groups";. >> >> I think better if we can follow the same patter to userDomains. >> > We can... but I do not see significant advantage of doing that. > >> >> -Ishara >> >> On Sat, Mar 4, 2017 at 8:01 PM, Vindula Jayawardana < >> [email protected]> wrote: >> >>> Hi, >>> >>> According to SCIM protocol specification[1], SCIM service providers may >>> support additional query parameters apart from the standard set of query >>> parameters in querying resources. Hence +1 for what Gayan has proposed here. >>> >>> I also agree with what Omindu has proposed. I think we could even add >>> the domain as an extension attribute rather adding it to username if >>> necessary. However, due to the fact that IS only supports one simple filter >>> with "eq" as the filter operation, by doing this way, we are limiting the >>> client's ability to query a resource using another filter. For an example >>> what if the client wants to query all users with "userType+EQ+student" in a >>> domain of "XXXX". Since one filter is already used, this kind of queries >>> will not be fitted in. But in the Gayan's method this can be done with the >>> following query request. >>> >>> /scim/v2/Users?filter=userType+EQ+student&domain=xxxx >>> >>> >>> [1] - https://tools.ietf.org/html/rfc7644#section-3.4.2 >>> >>> *Vindula Jayawardana* >>> Computer Science and Engineering Dept. >>> University of Moratuwa >>> mobile : +713462554 >>> Email : [email protected] >>> >>> <https://www.facebook.com/vindula.jayawardana> >>> <http://lk.linkedin.com/pub/vindula-jayawardana/a7/315/53b> >>> <https://plus.google.com/u/0/+VindulaJayawardana/posts> >>> <https://twitter.com/vindulajay> >>> >>> *“Respect is how to treat everyone, not just those you want to impress. >>> "* >>> >>> >>> *-Richard Branson-* >>> >>> >>> >>> On 3 March 2017 at 18:41, Omindu Rathnaweera <[email protected]> wrote: >>> >>>> Hi Gayan, >>>> >>>> Does the protocol permits introducing custom parameters as domain? If >>>> so +1 for using a param. Else, we can include the domain name as a part of >>>> the username (IINM we support this in C4 as well), so searching only in a >>>> particular domain will look like below. >>>> >>>> /scim/v2/Users?filter=userName+EQ+FOODOMAIN/* >>>> >>>> Also, should we look into searching within multiple domains ? Currently >>>> we can only search either in a single domain or in all domains. However, >>>> the identity store does not have this support yet. >>>> >>>> Regards, >>>> Omindu. >>>> >>>> On Thu, Mar 2, 2017 at 11:41 PM, Gayan Gunawardana <[email protected]> >>>> wrote: >>>> >>>>> Hi All, >>>>> >>>>> How are we going to support SCIM list all users and list all groups >>>>> operations when we have multiple user store domains. In C4 we could >>>>> iterate >>>>> through all user stores and fetch results but in C5 we highly discourage >>>>> such a functionality due to performance impact. >>>>> >>>>> Basically client need to provide user store domain, when it requires >>>>> data from secondary user store domains. >>>>> >>>>> My suggestion is to support custom parameter like "domain" so requests >>>>> will be like below. >>>>> >>>>> /scim/v2/Users?domain=xxxx >>>>> >>>>> /scim/v2/Users?startIndex=1&count=2&domain=xxxx >>>>> >>>>> >>>>> /scim/v2/Users?filter=userName+EQ+vindula&domain=xxxx >>>>> >>>>> >>>>> @Ishara, Johann, Ayoma appreciate your input. >>>>> >>>>> >>>>> Thanks, >>>>> >>>>> Gayan >>>>> >>>>> -- >>>>> Gayan Gunawardana >>>>> Software Engineer; WSO2 Inc.; http://wso2.com/ >>>>> Email: [email protected] >>>>> Mobile: +94 (71) 8020933 >>>>> >>>>> _______________________________________________ >>>>> Architecture mailing list >>>>> [email protected] >>>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>>>> >>>>> >>>> >>>> >>>> -- >>>> Omindu Rathnaweera >>>> Software Engineer, WSO2 Inc. >>>> Mobile: +94 771 197 211 <+94%2077%20119%207211> >>>> >>>> _______________________________________________ >>>> Architecture mailing list >>>> [email protected] >>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>>> >>>> >>> >>> _______________________________________________ >>> Architecture mailing list >>> [email protected] >>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>> >>> >> >> >> -- >> Ishara Karunarathna >> Associate Technical Lead >> WSO2 Inc. - lean . enterprise . middleware | wso2.com >> >> email: [email protected], blog: isharaaruna.blogspot.com, mobile: >> +94717996791 <+94%2071%20799%206791> >> >> >> > > > -- > Gayan Gunawardana > Software Engineer; WSO2 Inc.; http://wso2.com/ > Email: [email protected] > Mobile: +94 (71) 8020933 > -- Ishara Karunarathna Associate Technical Lead WSO2 Inc. - lean . enterprise . middleware | wso2.com email: [email protected], blog: isharaaruna.blogspot.com, mobile: +94717996791
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
