+Adding to the above as discussed in [1] Considering this requirement, we will add the following user attributes(if > exists), to the */me/association GET* response.
This approach is used, to have *only* a limited number of user-friendly attributes(sp: considering scenarios like user portals) and it was decided that the given three attributes(first name, last name, and email) satisfies this condition. Other than that,* to get any other user attribute*, the switch grant must be used. [1] "Updated invitation with note: [Discussion] Calling REST APIs On Behalf Of Associated User @ Thu Nov 21, 2019 11:30am - 12:30pm (IST) (WSO2 Engineering Group)" Regards, Tharindu. On Thu, Nov 21, 2019 at 5:16 PM Tharindu Bandara <[email protected]> wrote: > Hi all, > > >> - Returning user attributes with the */me/association GET* response >> is not suitable considering the API path. Therefore, the user ID of the >> associated user returned from this response will be used to call SCIM >> APIs(or any similar API to retrieve user attributes) to get user >> attributes >> of the associated user. >> >> >> - There might be some authorization issues with the existing >> implementation with this approach(Ex: The user portal is trying to call >> SCIM APIs for the associated user's attributes, with the currently >> authenticated user). But these issues need to be solved from the >> authorization level, as associated users are basically the same user, >> therefore anyone should have the privilege to retrieve their associated >> user attributes. >> >> For this requirement, we have decided to go with a switch grant type, > which will provide a token for an associated user. > > But having a limited set of user attributes in the */me/association GET* > response > could actually be a better option, given that the switching and getting a > token might decrease the performance when there is a large number of > switching to be done. > > For example, if a user portal needs to display all the associated user > accounts of the logged-in user, it needs user-friendly attributes > representing the associated accounts. In this case, if the */me/association > GET* response contains attributes like first name and last name, that > would be a better approach, other than obtaining tokens for each associated > user, then call SCIM */me* endpoint to obtain these attributes. > > Considering this requirement, we will add the following user attributes(if > exists), to the */me/association GET* response. > > - First name > - Last name > - Email > > [1] "[IAM] Calling REST APIs On-behalf Of My Associated Accounts"@ > [email protected] > > Regards, > Tharindu. > > On Wed, Nov 6, 2019 at 11:23 AM Tharindu Bandara <[email protected]> > wrote: > >> Hi all, >> >> We had a review meeting[1] yesterday and the following were discussed. >> >> *Participants: *+Ruwan Abeykoon <[email protected]> +Isura Karunaratne >> <[email protected]> +Thanuja Jayasinghe <[email protected]> +Maduranga >> Siriwardena <[email protected]> +Farasath Ahamed <[email protected]>* >> +Tharindu >> Bandara <[email protected]> * >> >> - Returning user attributes with the */me/association GET* response >> is not suitable considering the API path. Therefore, the user ID of the >> associated user returned from this response will be used to call SCIM >> APIs(or any similar API to retrieve user attributes) to get user >> attributes >> of the associated user. >> - There might be some authorization issues with the existing >> implementation with this approach(Ex: The user portal is trying to call >> SCIM APIs for the associated user's attributes, with the currently >> authenticated user). But these issues need to be solved from the >> authorization level, as associated users are basically the same user, >> therefore anyone should have the privilege to retrieve their associated >> user attributes. >> - The existing implementation for the federated associations is, the >> UserProfileAdmin admin service in the identity-framework handles all the >> API calls regarding the federated associations by directly calling the DAO >> layer. It lacks an OSGi service between the admin service and the DAO >> layer >> for federated associations. >> - A new OSGi service will be introduced in the framework with >> this effort, which will contain APIs to handle federated associations. >> - UserProfileAdmin service will be refactored to call the above >> OSGi service. >> - The associations REST APIs will call the same OSGi service in >> the framework for federated associations related APIs. >> >> [1] "Invitation: [Code Review] Federation Association REST APIs @ Tue Nov >> 5, 2019 3:30pm - 4:30pm (IST) (WSO2 Engineering Group)"@engineering-group >> >> Regards, >> Tharindu. >> >> On Mon, Nov 4, 2019 at 6:08 PM Tharindu Bandara <[email protected]> >> wrote: >> >>> Hi all, >>> >>> We had an offline discussion today with +Ishara Karunarathna >>> <[email protected]> +Malithi Edirisinghe <[email protected]> +Darshana >>> Gunawardana <[email protected]> +Isura Karunaratne <[email protected]> >>> +Tharindu >>> Bandara <[email protected]> . According to the discussion, it was >>> decided that the */{user-id}/association *and >>> */{user-id}/federated-association >>> *POST requests are not needed for this API, as such use case of >>> allowing an admin user to associate local/federated account with another is >>> not needed. I will remove these admin APIs from the APIs[1]. >>> >>> [1] https://app.swaggerhub.com/apis/WSO8/association/v1 >>> >>> Thanks, >>> Tharindu. >>> >>> On Wed, Oct 30, 2019 at 6:51 PM Tharindu Bandara <[email protected]> >>> wrote: >>> >>>> Hi all, >>>> >>>> Today we had a review meeting[1] to finalize the swagger API >>>> definition[2]. Please find the meeting notes below. >>>> >>>> *Participants:* +Thanuja Jayasinghe <[email protected]> +Isura >>>> Karunaratne <[email protected]> +Tharindu Bandara <[email protected]> >>>> >>>> *Notes:* >>>> >>>> - *[GET] : /me/associations * >>>> - This API returns a list of associated users. For an associated >>>> user, we would need the associated user's attributes. Therefore the >>>> possibility of retrieving user attributes requested via query params >>>> should >>>> be considered. >>>> - *[DELETE] : /me/federated-associations/{id}, [DELETE] >>>> : /{user-id}/federated-associations/{id}, [DELETE] >>>> : /me/associations/{user-id}* >>>> - These new APIs will be added to support deleting a given >>>> association. >>>> - The *{id} *parameter in the above should be a UUID for a >>>> federated association. As of now, all the federated associations are >>>> stored >>>> in "IDN_ASSOCIATED_ID" table, which does not have a unique >>>> identifier for an association. Therefore a new column will be added >>>> to the >>>> table "IDN_ASSOCIATED_ID" to have a UUID for an association >>>> entry. >>>> - The *{user-id} *parameter in above is the UUID for the user. >>>> Which would be the same Id in the* GET /me/association* response. >>>> >>>> [1] "Invitation: [Federated User Account Association REST APIs] API >>>> Review @ Wed Oct 30, 2019 4:30pm - 5:30pm (IST) (WSO2 Engineering Group)" >>>> [2] https://app.swaggerhub.com/apis/WSO8/association/v1 >>>> >>>> Regards, >>>> Tharindu. >>>> >>>> On Wed, Oct 30, 2019 at 1:10 PM Tharindu Bandara <[email protected]> >>>> wrote: >>>> >>>>> Hi Darshana, >>>>> >>>>> Why do we need the, >>>>>> >>>>>> - [POST] : /{user-id}/federated-associations >>>>>> >>>>>> The same API is available for the local account association. Now for >>>>> the federated account scenario, we grant this capability to an admin user, >>>>> as an admin API. >>>>> >>>>> We cannot provide a */me *API for this capability, as any user would >>>>> be able to associate any federated account with his account. This was the >>>>> concern raised earlier by +Isura Karunaratne <[email protected]>. >>>>> >>>>> The idea behind this approach is as a privileged user, an admin is >>>>> able to associate both local and a *federated* accounts to a given >>>>> user. >>>>> >>>>> Regards, >>>>> Tharindu. >>>>> >>>>> On Wed, Oct 30, 2019 at 12:55 PM Darshana Gunawardana < >>>>> [email protected]> wrote: >>>>> >>>>>> Hi Isura\Tharindu, >>>>>> >>>>>> Why do we need the, >>>>>>> >>>>>>> >>>>>>> - [POST] : /{user-id}/federated-associations >>>>>>> >>>>>>> >>>>>> Thanks, >>>>>> >>>>>> On Wed, Oct 30, 2019 at 10:00 AM Tharindu Bandara <[email protected]> >>>>>> wrote: >>>>>> >>>>>>> Hi Isura, >>>>>>> >>>>>>> I think this API is not required. If this is supported, anyone can >>>>>>>> associate federated accounts without authentication. That can cause a >>>>>>>> security issue. >>>>>>>> >>>>>>> >>>>>>> +1. I will remove the [POST] : /me/federated-associations API. >>>>>>> >>>>>>> Regards, >>>>>>> -- >>>>>>> *Tharindu Bandara* >>>>>>> Senior Software Engineer | WSO2 >>>>>>> >>>>>>> Email : [email protected] >>>>>>> Mobile : +94 714221776 >>>>>>> web : http://wso2.com >>>>>>> <https://www.google.com/url?q=http://wso2.com&sa=D&ust=1517653383990000&usg=AFQjCNFggB4bSJTKmdqKcBV0VY9xx1ABKg> >>>>>>> >>>>>>> https://wso2.com/signature >>>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> Regards, >>>>>> >>>>>> >>>>>> *Darshana Gunawardana*Technical Lead >>>>>> WSO2 Inc.; http://wso2.com >>>>>> >>>>>> *E-mail: [email protected] <[email protected]>* >>>>>> *Mobile: +94718566859*Lean . Enterprise . Middleware >>>>>> >>>>> >>>>> >>>>> -- >>>>> *Tharindu Bandara* >>>>> Senior Software Engineer | WSO2 >>>>> >>>>> Email : [email protected] >>>>> Mobile : +94 714221776 >>>>> web : http://wso2.com >>>>> <https://www.google.com/url?q=http://wso2.com&sa=D&ust=1517653383990000&usg=AFQjCNFggB4bSJTKmdqKcBV0VY9xx1ABKg> >>>>> >>>>> https://wso2.com/signature >>>>> >>>> >>>> >>>> -- >>>> *Tharindu Bandara* >>>> Senior Software Engineer | WSO2 >>>> >>>> Email : [email protected] >>>> Mobile : +94 714221776 >>>> web : http://wso2.com >>>> <https://www.google.com/url?q=http://wso2.com&sa=D&ust=1517653383990000&usg=AFQjCNFggB4bSJTKmdqKcBV0VY9xx1ABKg> >>>> >>>> https://wso2.com/signature >>>> >>> >>> >>> -- >>> *Tharindu Bandara* >>> Senior Software Engineer | WSO2 >>> >>> Email : [email protected] >>> Mobile : +94 714221776 >>> web : http://wso2.com >>> <https://www.google.com/url?q=http://wso2.com&sa=D&ust=1517653383990000&usg=AFQjCNFggB4bSJTKmdqKcBV0VY9xx1ABKg> >>> >>> https://wso2.com/signature >>> >> >> >> -- >> *Tharindu Bandara* >> Senior Software Engineer | WSO2 >> >> Email : [email protected] >> Mobile : +94 714221776 >> web : http://wso2.com >> <https://www.google.com/url?q=http://wso2.com&sa=D&ust=1517653383990000&usg=AFQjCNFggB4bSJTKmdqKcBV0VY9xx1ABKg> >> >> https://wso2.com/signature >> > > > -- > *Tharindu Bandara* > Senior Software Engineer | WSO2 > > Email : [email protected] > Mobile : +94 714221776 > web : http://wso2.com > <https://www.google.com/url?q=http://wso2.com&sa=D&ust=1517653383990000&usg=AFQjCNFggB4bSJTKmdqKcBV0VY9xx1ABKg> > > https://wso2.com/signature > -- *Tharindu Bandara* Senior Software Engineer | WSO2 Email : [email protected] Mobile : +94 714221776 web : http://wso2.com <https://www.google.com/url?q=http://wso2.com&sa=D&ust=1517653383990000&usg=AFQjCNFggB4bSJTKmdqKcBV0VY9xx1ABKg> https://wso2.com/signature
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
