Hi all, We had an offline meeting with +Darshana Gunawardana <darsh...@wso2.com> +Ishara Karunarathna <isha...@wso2.com> +Isura Karunaratne <is...@wso2.com> +Maduranga Siriwardena <madura...@wso2.com> +Thanuja Jayasinghe <than...@wso2.com> +Farasath Ahamed <farasa...@wso2.com> , regarding the concern raised by Darshana. We have discussed the following.
Changing the authorized user dynamically will be a custom approach that > will not work with any other resource server other than for the IS product > APIs. Therefore, fixing the authentication valve and using the header to call REST APIs on behalf of the associated user approach is not suitable. Since we have introduced a new grant type to switch and get tokens on behalf of the associated user, an appropriate way of doing this requirement is to get a new access token via the switch grant, then call REST APIs as required. Therefore, we will not be making any changes with the authentication valve to fulfill this requirement, but going with the above-approach using the switch grant. Regards, Tharindu. On Wed, Nov 20, 2019 at 10:50 AM Darshana Gunawardana <darsh...@wso2.com> wrote: > Hi Tharindu, > > IMO, we should keep the authorization at API level (resource server level) > simple as possible. And expect a token that have permission to access a > protected resource on behalf of a user. Changing the authorized user > dynamically will be a custom approach that will not work with any other > resource server other than for the IS product APIs. > > If the client wants to access API for any other user, it should, first > obtain a new access token that have permission to access a protected > resource on behalf of the new user and then invoke APIs with the new access > token. This way any resource server can be used to integrate with the > client, rather limiting to IS product APIs. > > When obtaining the new access token, authorization server can use the > context details like, > > - What's the existing LOA when obtained when issuing the previous > token as the user: *john* > - Any association details that user: *john* has > - The LOA that need to access requested resources for the new user: > *ben* > > and authorize the user with the required level and get the other details > like user consent, or any missing details etc. > > So, I'm -1 to go with suggested approach and if we have a specific need to > pull some more details of the associated users, we can fix those at the API > level. > > WDYT? > > Thanks, > > On Mon, Nov 18, 2019 at 6:58 PM Tharindu Bandara <tharin...@wso2.com> > wrote: > >> Hi all, >> >> Imagine my user account in WSO2 Identity Server is *john*. I have also >> one other associated user account in the identity server under the name, >> *ben*. >> >> I use an application, which shows all my user accounts in the identity >> server once I successfully logged in. >> >> As of now, the above scenario can be done successfully. The application >> can call the WSO2 Identity Server user account association APIs and list >> all the associated accounts on-behalf of me(once I logged in). >> >> But I want to see some of my attributes of the associated accounts(Ex: >> email addresses). This should be possible in a way that the application >> calls WSO2 IS SCIM APIs on-behalf of my associated accounts, then retrieve >> any attributes, without me logging in as each associated user(Ex: When I >> log in as *john*, the email address of *ben* should be shown by the >> application). >> >> The idea here is that all my associated accounts are essentially mine, >> therefore once logged in as a user, any of the subsequent REST API calls >> on-behalf of any associated user account, should be allowed. >> >> Please find the corresponding public JIRA >> <https://github.com/wso2/product-is/issues/6882>[2]. >> >> I had an initial discussion on this with +Isura Karunaratne >> <is...@wso2.com>. Based on that, I have implemented the following >> approach. >> >> We will introduce a new header called "AssociatedUserId". If this header >> is present for a REST API call, the authentication valve is responsible to >> read the fully qualified name of the associated user sent with this header. >> Then if a valid association exists with the authenticated user, the >> authentication valve will set the associated user in the carbon context, >> instead of the authenticated user, during the post-authentication stage. >> This will make sure that the REST API call is called on-behalf of the >> associated user identified with the above-mentioned header. >> >> Please find the pull request >> <https://github.com/wso2-extensions/identity-carbon-auth-rest/pull/92>[3] >> with this approach. >> >> Your valuable feedback is highly appreciated. >> >> PS: This requirement initially discussed at [1]. >> >> [1] "[IAM][IS 5.10.0] REST APIs For Federated Associations Of The >> User"@architecture-group >> [2] https://github.com/wso2/product-is/issues/6882 >> [3] https://github.com/wso2-extensions/identity-carbon-auth-rest/pull/92 >> >> Regards, >> Tharindu. >> -- >> *Tharindu Bandara* >> Senior Software Engineer | WSO2 >> >> Email : tharin...@wso2.com >> 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: darsh...@wso2.com <darsh...@wso2.com>* > *Mobile: +94718566859*Lean . Enterprise . Middleware > -- *Tharindu Bandara* Senior Software Engineer | WSO2 Email : tharin...@wso2.com 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 Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
