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
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
