Hi Fara, I think we can use following way to fix the problem.
- Check an OAuth application is registered for SP in doPreUpdateApplication method, if not, return and skip following steps. - Get the value of SaaS property in ApplicationMgtListener.doPreUpdateApplication() - *value1* - If *value1* is true, get the value of SaaS property in ApplicationMgtListener.doPostUpdateApplication() - *value2* - if *value1* is true and *value2* is false, we need to revoke existing tokens. This procoess can be executed assyncronusly. Thanks Isura. On Mon, May 8, 2017 at 11:20 PM, Farasath Ahamed <[email protected]> wrote: > > > On Monday, May 8, 2017, Pulasthi Mahawithana <[email protected]> wrote: > >> Hi Sathya, >> >> I think it would be better to do this with a application mgt listener >> rather than doing this at the validation time. We can use a >> "ApplicationMgtListener.doPostUpdateApplication()"[1] implementation and >> invalidate all the tokens issued to users from other tenants when the >> application is updated. >> > > I think we need to be careful if we go down the listener path and use > ApplicationMgtListener.doPostUpdateApplication() method. The reason is > that this method gets triggered even if you simply press the update button > in the Service Provider UI without doing any change. Also what is passed to > the method as arguments is the updated Service Provider object. > Therefore, it is a bit tricky to figure out whether a change happened at > all. > > Say, if we wrote the token revocation logic when SaaS option changes > within this method. So whenever someone presses the Service Provider UI > after doing a change(or not). It will be a tricky situation to figure out > what the change was basically. (Did someone disable Saas or was it already > off?). This method will also be called for unrelated changes like an update > to description etc. > > And as of now we only remove cache entries for any update in SP triggered > in [1]. That is safe even no change happened to SP at all. What we lose is > the cached entries which we can retrieve from DB. But what we are proposing > here is to revoke tokens upon an update in SP, therefore, we need to be > careful. > > IMO considering that we don't have a straightforward way to identify the > change in the update SP passed to [1] it would be better to have a SaaS > check required places whenever the user tenant domain and SP tenant domain > are different. > > or else we need to figure out a way to pass that SaaS option was changed > explicitly. > > > [1] https://github.com/wso2/carbon-identity-framework/blob/m > aster/components/application-mgt/org.wso2.carbon.identity.ap > plication.mgt/src/main/java/org/wso2/carbon/identity/applica > tion/mgt/listener/AbstractApplicationMgtListener.java#L43 > > > >> >> On Mon, May 8, 2017 at 7:03 PM, Sathya Bandara <[email protected]> wrote: >> >>> Hi All, >>> >>> This is in relation to issue [1] which happens when using a valid access >>> token issued to a SaaS enabled application (application in a separate >>> domain. User from another tenant domain). After disabling SaaS, it is still >>> possible to use the same access token to access the UserInfo endpoint for >>> this user from another tenant. Also it is possible to obtain a new access >>> token for the saas-disabled application by using the issued refresh token >>> for a different tenant user. >>> >>> For this I have added functionality to validate tenant domain and to >>> check if the SP is SaaS enabled before granting access to the userInfo >>> endpoint. It is evident that we should revoke the refresh token such that >>> user is not permitted to obtain further access tokens for the application. >>> In addition to this is it required to invalidate the already-issued access >>> token? >>> >>> Appreciate your help on this. >>> >>> [1] https://wso2.org/jira/browse/IDENTITY-4981 >>> >>> Best regards, >>> Sathya >>> >>> -- >>> Sathya Bandara >>> Software Engineer >>> WSO2 Inc. http://wso2.com >>> Mobile: (+94) 715 360 421 <+94%2071%20411%205032> >>> >>> <+94%2071%20411%205032> >>> >> >> >> >> -- >> *Pulasthi Mahawithana* >> Senior Software Engineer >> WSO2 Inc., http://wso2.com/ >> Mobile: +94-71-5179022 <+94%2071%20517%209022> >> Blog: https://medium.com/@pulasthi7/ >> >> <https://wso2.com/signature> >> > -- *Isura Dilhara Karunaratne* Senior Software Engineer | WSO2 Email: [email protected] Mob : +94 772 254 810 Blog : http://isurad.blogspot.com/
_______________________________________________ Dev mailing list [email protected] http://wso2.org/cgi-bin/mailman/listinfo/dev
