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

Reply via email to