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> >
_______________________________________________ Dev mailing list [email protected] http://wso2.org/cgi-bin/mailman/listinfo/dev
