Hi Sathya, Does the spec [1] contains any detail about access token revocation?
It is evident that we should revoke the refresh token such that user is not > permitted to obtain further access tokens for the application. yes it is obvious that we should not allow to generate access tokens using refresh tokens when SaaS is disabled. In addition to this is it required to invalidate the already-issued access > token? IMO the authorization server should revoke even already issued access tokens when it disabled SaaS. From disabling Saas it conveys that this application is no longer shared among other tenants. WDYT? [1] https://tools.ietf.org/html/rfc7009 Thanks, Hasanthi Dissanayake Software Engineer | WSO2 E: hasan...@wso2.com M :0718407133| http://wso2.com <http://wso2.com/> On Mon, May 8, 2017 at 11:20 PM, Farasath Ahamed <farasa...@wso2.com> wrote: > > > On Monday, May 8, 2017, Pulasthi Mahawithana <pulast...@wso2.com> 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 <sat...@wso2.com> 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 > Dev@wso2.org > http://wso2.org/cgi-bin/mailman/listinfo/dev > >
_______________________________________________ Dev mailing list Dev@wso2.org http://wso2.org/cgi-bin/mailman/listinfo/dev
