On Tuesday, May 9, 2017, Isura Karunaratne <[email protected]> wrote: > 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. > > +1. Yes, this solves the problem.
Can we also consider other scenarios where we need to do the same like say a grant type being disabled? ie. Not allowing a token obtained with a grant type that is disabled by the time it is used > > > Thanks > Isura. > > On Mon, May 8, 2017 at 11:20 PM, Farasath Ahamed <[email protected] > <javascript:_e(%7B%7D,'cvml','[email protected]');>> wrote: > >> >> >> On Monday, May 8, 2017, Pulasthi Mahawithana <[email protected] >> <javascript:_e(%7B%7D,'cvml','[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] <javascript:_e(%7B%7D,'cvml','[email protected]');> > Mob : +94 772 254 810 > Blog : http://isurad.blogspot.com/ > > > > -- Farasath Ahamed Software Engineer, WSO2 Inc.; http://wso2.com Mobile: +94777603866 Blog: blog.farazath.com Twitter: @farazath619 <https://twitter.com/farazath619> <http://wso2.com/signature>
_______________________________________________ Dev mailing list [email protected] http://wso2.org/cgi-bin/mailman/listinfo/dev
