On Wed, Jan 24, 2018 at 2:20 PM, Maduranga Siriwardena <[email protected]>
wrote:

> If the user is in secondary userstore, fully qualified username contains
> "/" character. But seems to be we can't send url encoded "/" characters
> (%2F) in path parameters. We are evaluating possible solutions for this. If
> this is not an option, we are planing to base 64 encode the username and
> then url encode it.
>
> We already has a web application with name api#identity#user [1]. So we
> are planing to use the same repository for this code also.
>

Yes. We can use the same application.

>
> [1] https://github.com/wso2-extensions/identity-governance/
> tree/v1.0.38/components/org.wso2.carbon.identity.user.endpoint
>
> Thanks,
>
> On Tue, Jan 23, 2018 at 10:40 AM, Maduranga Siriwardena <
> [email protected]> wrote:
>
>>
>>
>> On Tue, Jan 23, 2018 at 10:35 AM, Omindu Rathnaweera <[email protected]>
>> wrote:
>>
>>>
>>> Hi Maduranga,
>>>
>>> On Tue, Jan 23, 2018 at 10:23 AM, Maduranga Siriwardena <
>>> [email protected]> wrote:
>>>
>>>> Hi all,
>>>>
>>>> Web app name we have come up for this endpoint
>>>> is api#identity#user#v1.0 and the path for the endpoint is
>>>> /pi/users/{userId}. So the whole endpoint would be
>>>>
>>>>    - for super tenant,
>>>>
>>>> /api/identity/user/v1.0/pi/users/{userId}
>>>>
>>>>
>>>>    - for tenant,
>>>>
>>>> /t/{tenant-domain}/api/identity/user/v1.0/pi/users/{userId}
>>>>
>>>>
IMO  we can use following format,

/ t/{tenant-domain}/api/identity/user/v1.0/pi-info/{id}


Thanks
Isura.

>
>>>> Our initial plan was to use the ID used in Pseudonyms for username
>>>> feature [1]. But as the ID used by Pseudonyms for username feature is not
>>>> available to outside, we cannot use it here. Next option available to us is
>>>> the ID used in SCIM. But as it is not mandatory to have SCIM ID in system
>>>> (when SCIM is disabled), we cannot use this option also.
>>>>
>>>> Because of above reasons, we are planing to use base 64 encoded fully
>>>> qualified username as the userId in the above request.
>>>>
>>>
>>> Would like to know the rationale behind base64 encoding the username.
>>> Also if it has to be b64 encoded for some reason then it should be base64
>>> URL encoded I believe.
>>>
>>
>> Yes this should be url encoding.
>>
>>>
>>>
>>>>
>>>> Do you have any suggestions?
>>>>
>>>> [1] [Architecture] GDPR - Pseudonyms For Username
>>>>
>>>> Thanks,
>>>>
>>>> On Mon, Jan 22, 2018 at 5:52 PM, Hasintha Indrajee <[email protected]>
>>>> wrote:
>>>>
>>>>> In a federated user scenario, we neither have user information nor
>>>>> email address of the user in a case if the user is not JIT. Hence we won't
>>>>> be able to share consents with user in an offline method. But still for
>>>>> federated users we need to maintain consents which we give out to SPs. We
>>>>> can process this offline and store somewhere (consent info ready for
>>>>> download). The way we share will depend. eg - For the users who have 
>>>>> emails
>>>>> we can send them through an email (as a download link). If not we can 
>>>>> share
>>>>> those information through another medium (eg - user profile at a later
>>>>> login)
>>>>>
>>>>> On Mon, Jan 22, 2018 at 5:40 PM, Ruwan Abeykoon <[email protected]>
>>>>> wrote:
>>>>>
>>>>>> Hi Hasintha,
>>>>>> We do not need to export anything we do not keep in our databases.
>>>>>> Could you please explain further if we need to do anything extra for
>>>>>> Federated case.
>>>>>>
>>>>>> Cheers,
>>>>>> Ruwan
>>>>>>
>>>>>> On Mon, Jan 22, 2018 at 5:33 PM, Hasintha Indrajee <[email protected]
>>>>>> > wrote:
>>>>>>
>>>>>>> Just a quick question. How are we going to cater consents for
>>>>>>> federated user ? Having consent from 3rd party IDP to IS will not be 
>>>>>>> enough
>>>>>>> AFAIU. If we are sharing those information through an SP we need to
>>>>>>> maintain those consents as well. WDYT ?
>>>>>>>
>>>>>>> In that case how can federated users download their consents ?
>>>>>>>
>>>>>>> On Mon, Jan 22, 2018 at 5:25 PM, Omindu Rathnaweera <[email protected]
>>>>>>> > wrote:
>>>>>>>
>>>>>>>> Hi Maduranga,
>>>>>>>>
>>>>>>>> In the consent API we do not have the option to get multiple
>>>>>>>> receipts, the API only returns a list of receipt IDs for a given search
>>>>>>>> criteria. If you need to include receipt data of all the consent 
>>>>>>>> entries,
>>>>>>>> you will have to iterate through all the consent IDs and fetch the
>>>>>>>> individual receipts. Keep in mind that this will likely to generate a
>>>>>>>> payload of a considerable size.
>>>>>>>>
>>>>>>>> Regards,
>>>>>>>> Omindu.
>>>>>>>>
>>>>>>>>
>>>>>>>> On Mon, Jan 22, 2018 at 5:12 PM, Maduranga Siriwardena <
>>>>>>>> [email protected]> wrote:
>>>>>>>>
>>>>>>>>> Hi all,
>>>>>>>>>
>>>>>>>>> We are creating a REST API to export user information for IS 5.5.0.
>>>>>>>>>
>>>>>>>>> Swagger at [1] is the initial design of the API.
>>>>>>>>>
>>>>>>>>> In the initial phase we are allowing the data to be exported only
>>>>>>>>> by the owner of the profile.
>>>>>>>>>
>>>>>>>>> At the moment we are planing to export basic user profile
>>>>>>>>> information and the consents user has given. Response JSON has 2 
>>>>>>>>> parts in
>>>>>>>>> it.
>>>>>>>>>
>>>>>>>>>    - basic: this part will have the users profile information
>>>>>>>>>    (claims) in wso2 dialect
>>>>>>>>>    - consents: this part will have an array of consents user has
>>>>>>>>>    provided to the Identity Server. Though in the swagger it is 
>>>>>>>>> represented
>>>>>>>>>    with the ID of the consent receipt, the actual response will 
>>>>>>>>> consist of the
>>>>>>>>>    whole consent receipt. (Refer mail thread [2] @
>>>>>>>>>    [email protected] for more information)
>>>>>>>>>
>>>>>>>>> Below is a sample JSON response.
>>>>>>>>>
>>>>>>>>> {
>>>>>>>>>   "basic": {
>>>>>>>>>     "http://wso2.org/claims/userid":
>>>>>>>>> "92d6513e-f4ca-4438-b403-98380695ed08",
>>>>>>>>>     "http://wso2.org/claims/username": "maduranga",
>>>>>>>>>     "http://wso2.org/claims/givenname": "Maduranga",
>>>>>>>>>     "http://wso2.org/claims/lastname": "Siriwardena",
>>>>>>>>>     "http://wso2.org/claims/emailaddress": "[email protected]",
>>>>>>>>>     "http://wso2.org/claims/telephone": "+94711111111
>>>>>>>>> <+94%2071%20111%201111>"
>>>>>>>>>   },
>>>>>>>>>   "consents": [
>>>>>>>>>     {
>>>>>>>>>       "id": "bc53e7bd-013d-4020-b522-1915ada1f305"
>>>>>>>>>     }
>>>>>>>>>   ]
>>>>>>>>> }
>>>>>>>>>
>>>>>>>>> Do you have any suggestions for additional types of information to
>>>>>>>>> be included in the response?
>>>>>>>>>
>>>>>>>>> [1] https://app.swaggerhub.com/apis/Maduranga/PersonalInform
>>>>>>>>> ationExport/1.0.0
>>>>>>>>> [2] Consent Management APIs for IS 5.5.0
>>>>>>>>>
>>>>>>>>> Thanks,
>>>>>>>>>
>>>>>>>>> --
>>>>>>>>> Maduranga Siriwardena
>>>>>>>>> Senior Software Engineer
>>>>>>>>> WSO2 Inc; http://wso2.com/
>>>>>>>>>
>>>>>>>>> Email: [email protected]
>>>>>>>>> Mobile: +94718990591 <+94%2071%20899%200591>
>>>>>>>>> Blog: *https://madurangasiriwardena.wordpress.com/
>>>>>>>>> <https://madurangasiriwardena.wordpress.com/>*
>>>>>>>>> <http://wso2.com/signature>
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> --
>>>>>>>> Omindu Rathnaweera
>>>>>>>> Senior Software Engineer, WSO2 Inc.
>>>>>>>> Mobile: +94 771 197 211 <077%20119%207211>
>>>>>>>>
>>>>>>>> _______________________________________________
>>>>>>>> Architecture mailing list
>>>>>>>> [email protected]
>>>>>>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> Hasintha Indrajee
>>>>>>> WSO2, Inc.
>>>>>>> Mobile:+94 771892453 <+94%2077%20189%202453>
>>>>>>>
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> Dev mailing list
>>>>>>> [email protected]
>>>>>>> http://wso2.org/cgi-bin/mailman/listinfo/dev
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Hasintha Indrajee
>>>>> WSO2, Inc.
>>>>> Mobile:+94 771892453 <+94%2077%20189%202453>
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> Dev mailing list
>>>>> [email protected]
>>>>> http://wso2.org/cgi-bin/mailman/listinfo/dev
>>>>>
>>>>>
>>>>
>>>>
>>>> --
>>>> Maduranga Siriwardena
>>>> Senior Software Engineer
>>>> WSO2 Inc; http://wso2.com/
>>>>
>>>> Email: [email protected]
>>>> Mobile: +94718990591 <+94%2071%20899%200591>
>>>> Blog: *https://madurangasiriwardena.wordpress.com/
>>>> <https://madurangasiriwardena.wordpress.com/>*
>>>> <http://wso2.com/signature>
>>>>
>>>> _______________________________________________
>>>> Dev mailing list
>>>> [email protected]
>>>> http://wso2.org/cgi-bin/mailman/listinfo/dev
>>>>
>>>>
>>> Thanks,
>>> Omindu.
>>>
>>> --
>>> Omindu Rathnaweera
>>> Senior Software Engineer, WSO2 Inc.
>>> Mobile: +94 771 197 211 <+94%2077%20119%207211>
>>>
>>
>>
>>
>> --
>> Maduranga Siriwardena
>> Senior Software Engineer
>> WSO2 Inc; http://wso2.com/
>>
>> Email: [email protected]
>> Mobile: +94718990591 <+94%2071%20899%200591>
>> Blog: *https://madurangasiriwardena.wordpress.com/
>> <https://madurangasiriwardena.wordpress.com/>*
>> <http://wso2.com/signature>
>>
>
>
>
> --
> Maduranga Siriwardena
> Senior Software Engineer
> WSO2 Inc; http://wso2.com/
>
> Email: [email protected]
> Mobile: +94718990591 <+94%2071%20899%200591>
> Blog: *https://madurangasiriwardena.wordpress.com/
> <https://madurangasiriwardena.wordpress.com/>*
> <http://wso2.com/signature>
>
> _______________________________________________
> Architecture mailing list
> [email protected]
> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>
>


-- 

*Isura Dilhara Karunaratne*
Associate Technical Lead | WSO2
Email: [email protected]
Mob : +94 772 254 810 <+94%2077%20225%204810>
Blog : http://isurad.blogspot.com/
_______________________________________________
Architecture mailing list
[email protected]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Reply via email to