Hi On Tue, May 9, 2017 at 10:31 AM, Farasath Ahamed <[email protected]> wrote:
> > > 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. > +1 for implementing in the discussed way. > > Can we also consider other scenarios where we need to do the same like say > a grant type being disabled? > With the current implementation we have two types of token application and application user tokens and we do not keep grant type information. Due to that reason we may not be able to do this. -Ishara > > 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]> >> 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 <+94%2077%20225%204810> >> 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> > > > > -- Ishara Karunarathna Associate Technical Lead WSO2 Inc. - lean . enterprise . middleware | wso2.com email: [email protected], blog: isharaaruna.blogspot.com, mobile: +94717996791
_______________________________________________ Dev mailing list [email protected] http://wso2.org/cgi-bin/mailman/listinfo/dev
