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
_______________________________________________ Dev mailing list [email protected] http://wso2.org/cgi-bin/mailman/listinfo/dev
