Do we need to add security related information of the user also to the response?
For example the security questions configured by the user Thanks, On Thu, Feb 8, 2018 at 12:02 PM, Maduranga Siriwardena <[email protected]> wrote: > Hi all, > > Based on the discussions had offline we did few changes to the api. We > have come up with 3 endpoints. > > /api/identity/user/v1.0/me > Get the personal information of authenticated user. > > /api/identity/user/v1.0/pi-info/{userId} > Get the personal information of the user with the given id. Users with > "administrative" privileges can invoke this api. We need to decide what > level authorization needed for this operation. > > /api/identity/user/v1.0/pi-info?username=xxxx > Get the user ids and usernames of the given username pattern. This might > not be implemented at the moment. > > Thanks, > Maduranga. > > On Wed, Jan 24, 2018 at 8:33 PM, Isura Karunaratne <[email protected]> wrote: > >> >> >> 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/t >>> ree/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 >> >> > > > -- > 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 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
