IMO, returning the username with userstore domain in the response may be seen as an unwanted sensitive information leak in this setup. Ideally in these kind of scenarios expectation is service provider doesn't need to know the user store domain name where his users are created. Therefore they can provision without the user store domain in the username. And response also will return the username only.
If they send a invalid or unauthorized domain I think we have to return back and unauthorized error saying "Not authorized to provision to the domain". But then again I am not sure if the service provider can carry out all SCIM operations without knowing the domain name. Regards, Johann. On Tue, Sep 19, 2017 at 12:40 AM, Darshana Gunawardana <[email protected]> wrote: > There is no hard rule to specify which one should be the correct approach > in this case. Since there is always room to override this setting using > specific SP's configuration, I think current approach is ok. > > Thanks, > > On Tue, Sep 19, 2017 at 12:30 AM, Gayan Gunawardana <[email protected]> > wrote: > >> >> >> On Tue, Sep 19, 2017 at 12:13 AM, Darshana Gunawardana <[email protected] >> > wrote: >> >>> Since we returning the correct username in the response, its should be >>> ok. This is a configuration issue if the client is expecting otherway. >>> >> I think it is better if there is a way to inform client application about >> configuration issue. There is a possibility that SCIM consumers may not >> look into admin console configurations at all. Also there is a high >> possibility to client application to depend on only http response code. >> >>> >>> Thanks, >>> >>> On Tue, Sep 19, 2017 at 12:10 AM, Gayan Gunawardana <[email protected]> >>> wrote: >>> >>>> >>>> >>>> On Mon, Sep 18, 2017 at 11:42 PM, Darshana Gunawardana < >>>> [email protected]> wrote: >>>> >>>>> Ok, now you asked the real question :) >>>>> >>>>> Yes I agree with the expected results you mentioned for all three >>>>> cases. I have checked this behaviour on a latest pack[1][2] and it only >>>>> provision user to specified userstore in the SP configuration in the case >>>>> 3 >>>>> which is a reasonable behariour. (I'm using locally built 5.4.0-SNAPSHOT >>>>> version, which is slightly newer than 5.4.0-alpha2) >>>>> >>>>> What is the pack that you have tried? >>>>> >>>> I have used 5.4.0-alpha2 and your observation is correct i haven't get >>>> expected result due to some wrong configurations. >>>> We have to think about case 03 carefully because client application may >>>> understand as provisioning is successful but it may not be the intended >>>> user store. >>>> >>>>> >>>>> [1] >>>>> Sample Request: >>>>> POST /wso2/scim/Users HTTP/1.1 >>>>> Host: localhost:9443 >>>>> Content-Type: application/json >>>>> Authorization: Basic YWRtaW46YWRtaW4= >>>>> Cache-Control: no-cache >>>>> Postman-Token: a07e5cab-f4e9-52dd-d245-1b65552c5539 >>>>> >>>>> { >>>>> "schemas": [ >>>>> >>>>> ], >>>>> "userName": "LDAP/[email protected]", >>>>> "password": "darray" >>>>> } >>>>> >>>>> [2] >>>>> Sample Response: >>>>> { >>>>> "meta": { >>>>> "created": "2017-09-18T23:28:23", >>>>> "location": "https://localhost:9443/wso2/s >>>>> cim/Users/3d5b1153-79ef-4ea9-9b47-31c92a2bd3dd", >>>>> "lastModified": "2017-09-18T23:28:23" >>>>> }, >>>>> "schemas": [ >>>>> "urn:scim:schemas:core:1.0" >>>>> ], >>>>> "id": "3d5b1153-79ef-4ea9-9b47-31c92a2bd3dd", >>>>> "userName": "H2/[email protected]" >>>>> } >>>>> >>>>> Thanks, >>>>> >>>>> >>>>> On Mon, Sep 18, 2017 at 11:00 PM, Gayan Gunawardana <[email protected]> >>>>> wrote: >>>>> >>>>>> >>>>>> >>>>>> On Mon, Sep 18, 2017 at 10:27 PM, Darshana Gunawardana < >>>>>> [email protected]> wrote: >>>>>> >>>>>>> >>>>>>> >>>>>>> On Mon, Sep 18, 2017 at 7:58 PM, Gayan Gunawardana <[email protected]> >>>>>>> wrote: >>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> When user store selected from Inbound Provisioning Configuration >>>>>>>> should we allow to provision other user stores as well ? >>>>>>>> >>>>>>> >>>>>>> No. >>>>>>> >>>>>>> >>>>>>>> For an example if we selected "TEST" as user store from Inbound >>>>>>>> Provisioning Configuration, can we provision to PRIMARY user store as >>>>>>>> well ? >>>>>>>> >>>>>>> >>>>>>> No. >>>>>>> >>>>>> Thanks Darshana but currently it works other way. >>>>>> >>>>>>> >>>>>>> Given that you are already an expert on the provisioning area, I >>>>>>> suppose you already knew the answers for above questions but you have a >>>>>>> followup question in mind. May I know what that is? :) >>>>>>> >>>>>> I do not have specific follow up question :) just wanted to avoid >>>>>> confusion of sending user store domain in request and selecting user >>>>>> store >>>>>> domain from service provider. >>>>>> case 01: Do not select user store domain from service provider and >>>>>> sending user store domain in the request. >>>>>> expectation: User store domain can be extracted from request and >>>>>> provision to respective user store. >>>>>> >>>>>> case 02: Select user store domain from service provider and send >>>>>> request without user store domain. >>>>>> expectation: User store domain can be taken from service provider >>>>>> configurations. >>>>>> >>>>>> case 03: Select user store domain from service provider and send >>>>>> different user store domain in the request. >>>>>> expectation: In this case we can either throw an exception or we can >>>>>> provision users to user store configured in service provider. >>>>>> >>>>>> I guess you are agree with case 01, case 02 but what about case 03 ? >>>>>> >>>>>>> >>>>>>> Thanks, >>>>>>> >>>>>>> >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Gayan >>>>>>>> -- >>>>>>>> Gayan Gunawardana >>>>>>>> Senior Software Engineer; WSO2 Inc.; http://wso2.com/ >>>>>>>> Email: [email protected] >>>>>>>> Mobile: +94 (71) 8020933 >>>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> -- >>>>>>> Regards, >>>>>>> >>>>>>> >>>>>>> *Darshana Gunawardana*Technical Lead >>>>>>> WSO2 Inc.; http://wso2.com >>>>>>> >>>>>>> *E-mail: [email protected] <[email protected]>* >>>>>>> *Mobile: +94718566859 <+94%2071%20856%206859>*Lean . Enterprise . >>>>>>> Middleware >>>>>>> >>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> Gayan Gunawardana >>>>>> Senior Software Engineer; WSO2 Inc.; http://wso2.com/ >>>>>> Email: [email protected] >>>>>> Mobile: +94 (71) 8020933 >>>>>> >>>>> >>>>> >>>>> >>>>> -- >>>>> Regards, >>>>> >>>>> >>>>> *Darshana Gunawardana*Technical Lead >>>>> WSO2 Inc.; http://wso2.com >>>>> >>>>> *E-mail: [email protected] <[email protected]>* >>>>> *Mobile: +94718566859 <+94%2071%20856%206859>*Lean . Enterprise . >>>>> Middleware >>>>> >>>> >>>> >>>> >>>> -- >>>> Gayan Gunawardana >>>> Senior Software Engineer; WSO2 Inc.; http://wso2.com/ >>>> Email: [email protected] >>>> Mobile: +94 (71) 8020933 >>>> >>> >>> >>> >>> -- >>> Regards, >>> >>> >>> *Darshana Gunawardana*Technical Lead >>> WSO2 Inc.; http://wso2.com >>> >>> *E-mail: [email protected] <[email protected]>* >>> *Mobile: +94718566859 <+94%2071%20856%206859>*Lean . Enterprise . >>> Middleware >>> >> >> >> >> -- >> Gayan Gunawardana >> Senior Software Engineer; WSO2 Inc.; http://wso2.com/ >> Email: [email protected] >> Mobile: +94 (71) 8020933 >> > > > > -- > Regards, > > > *Darshana Gunawardana*Technical Lead > WSO2 Inc.; http://wso2.com > > *E-mail: [email protected] <[email protected]>* > *Mobile: +94718566859 <+94%2071%20856%206859>*Lean . Enterprise . > Middleware > > _______________________________________________ > Dev mailing list > [email protected] > http://wso2.org/cgi-bin/mailman/listinfo/dev > > -- Thanks & Regards, *Johann Dilantha Nallathamby* Senior Lead Solutions Engineer WSO2, Inc. lean.enterprise.middleware Mobile - *+94777776950* Blog - *http://nallaa.wordpress.com <http://nallaa.wordpress.com>*
_______________________________________________ Dev mailing list [email protected] http://wso2.org/cgi-bin/mailman/listinfo/dev
