Re: [Dev] [IS] Authorization granted for a SP for a different tenant's user when SaaS is disabled

[Ishara Karunarathna]

Hi

On Tue, May 9, 2017 at 10:31 AM, Farasath Ahamed  wrote:

>
>
> On Tuesday, May 9, 2017, Isura Karunaratne  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 
>> wrote:
>>
>>>
>>>
>>> On Monday, May 8, 2017, Pulasthi Mahawithana  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  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>
>
> 

Re: [Dev] [IS] Authorization granted for a SP for a different tenant's user when SaaS is disabled

[Farasath Ahamed]

On Tuesday, May 9, 2017, Isura Karunaratne  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  > wrote:
>
>>
>>
>> On Monday, May 8, 2017, Pulasthi Mahawithana > > 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  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/
>>>
>>> 
>>>
>>
>
>
> --
>
> *Isura Dilhara Karunaratne*
> Senior Software Engineer | WSO2
> Email: is...@wso2.com 

Re: [Dev] [IS] Authorization granted for a SP for a different tenant's user when SaaS is disabled

[Sathya Bandara]

Hi Hasanthi,

On Tue, May 9, 2017 at 8:41 AM, Hasanthi Purnima Dissanayake <
hasan...@wso2.com> wrote:

> Hi Sathya,
>
> Does the spec [1] contains any detail about access token revocation?
>
> According to the Oauth 2 spec, revocation of a refresh token should also
> invalidate all access tokens based on the same authorization grant. If the
> token passed to the revocation request is an access token the server may or
> may not revoke the respective refresh token depending on the authorization
> server's revocation policy. Independent of the revocation mechanisms, the
> authorization server may invalidate tokens in order to mitigate security
> threats.
>
> 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 
>
> On Mon, May 8, 2017 at 11:20 PM, Farasath Ahamed 
> wrote:
>
>>
>>
>> On Monday, May 8, 2017, Pulasthi Mahawithana  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  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 

Re: [Dev] [IS] Authorization granted for a SP for a different tenant's user when SaaS is disabled

[Isura Karunaratne]

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  wrote:

>
>
> On Monday, May 8, 2017, Pulasthi Mahawithana  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  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/
>>
>> 
>>
>


-- 

*Isura Dilhara Karunaratne*
Senior Software Engineer | WSO2
Email: is...@wso2.com
Mob : +94 772 254 810
Blog : http://isurad.blogspot.com/
___
Dev mailing list
Dev@wso2.org
http://wso2.org/cgi-bin/mailman/listinfo/dev

Re: [Dev] [IS] Authorization granted for a SP for a different tenant's user when SaaS is disabled

[Hasanthi Purnima Dissanayake]

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 

On Mon, May 8, 2017 at 11:20 PM, Farasath Ahamed  wrote:

>
>
> On Monday, May 8, 2017, Pulasthi Mahawithana  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  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/
>>
>> 
>>
>
> ___
> 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

Re: [Dev] [IS] Authorization granted for a SP for a different tenant's user when SaaS is disabled

[Farasath Ahamed]

On Monday, May 8, 2017, Pulasthi Mahawithana  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  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/
>
> 
>
___
Dev mailing list
Dev@wso2.org
http://wso2.org/cgi-bin/mailman/listinfo/dev

Re: [Dev] [IS] Authorization granted for a SP for a different tenant's user when SaaS is disabled

[Pulasthi Mahawithana]

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.

[1] https://github.com/wso2/carbon-identity-framework/
blob/master/components/application-mgt/org.wso2.carbon.identity.application.
mgt/src/main/java/org/wso2/carbon/identity/application/mgt/listener/
AbstractApplicationMgtListener.java#L43

On Mon, May 8, 2017 at 7:03 PM, Sathya Bandara  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/


___
Dev mailing list
Dev@wso2.org
http://wso2.org/cgi-bin/mailman/listinfo/dev

[Dev] [IS] Authorization granted for a SP for a different tenant's user when SaaS is disabled

[Sathya Bandara]

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>
___
Dev mailing list
Dev@wso2.org
http://wso2.org/cgi-bin/mailman/listinfo/dev