[IdP Mobile] SLO redirect issue with client certificate

Forge Component
(2)
Published on 16 Apr by Telmo Martins
2 votes
Published on 16 Apr by Telmo Martins

We have an issue with the redirect of the SLO request.

When an user logs in, he has to select a client certificate and then fill in his username and password.

When the app isn't closed before the user logs out then SLO request is working as designed. The redirect is working and the LogoutCallback_SystemBrowser block is triggered.

If the user closes the app (not open in background) without logging out, starts the app again and then tries to log out, the redirect isn't working. I see a LogoutResponse in the message log, but the response isn't processed. The user is logged out on Azure AD, his session is killed on IdP but remains logged in on OutSystems.

The only difference with the first scenario is that in the second one the user has to select his client certificate again and in the first he didn't.

How can I make sure the redirects for SLO are working correctly?

christopher torfs wrote:

We have an issue with the redirect of the SLO request.

When an user logs in, he has to select a client certificate and then fill in his username and password.

When the app isn't closed before the user logs out then SLO request is working as designed. The redirect is working and the LogoutCallback_SystemBrowser block is triggered.

If the user closes the app (not open in background) without logging out, starts the app again and then tries to log out, the redirect isn't working. I see a LogoutResponse in the message log, but the response isn't processed. The user is logged out on Azure AD, his session is killed on IdP but remains logged in on OutSystems.

The only difference with the first scenario is that in the second one the user has to select his client certificate again and in the first he didn't.

How can I make sure the redirects for SLO are working correctly?

Can somebody help me with this issue?


Hi,

I'm assuming that the session is still active in the system browser before he perform the logout, correct? Ie the web idP session is still active? (you can access to /IdP/ from the device browser just to confirm that you are still logged in).

Also, you can see a LogoutRequest in the log? With NameId and sessionIndex fulfilled in the xml message?

The LogoutResponse it's empty in the log? (ie, no xml)


Regards


Telmo Martins wrote:

Hi,

I'm assuming that the session is still active in the system browser before he perform the logout, correct? Ie the web idP session is still active? (you can access to /IdP/ from the device browser just to confirm that you are still logged in).

Also, you can see a LogoutRequest in the log? With NameId and sessionIndex fulfilled in the xml message?

The LogoutResponse it's empty in the log? (ie, no xml)


Regards



Hi,

The session on IdP is still active when the user performs the logout.

I see a LogoutRequest in the log with NameId and SessionIndex fulfilled in the xml.

The LogoutResponse is not empty.


Regards

christopher torfs wrote:

Telmo Martins wrote:

Hi,

I'm assuming that the session is still active in the system browser before he perform the logout, correct? Ie the web idP session is still active? (you can access to /IdP/ from the device browser just to confirm that you are still logged in).

Also, you can see a LogoutRequest in the log? With NameId and sessionIndex fulfilled in the xml message?

The LogoutResponse it's empty in the log? (ie, no xml)


Regards



Hi,

The session on IdP is still active when the user performs the logout.

I see a LogoutRequest in the log with NameId and SessionIndex fulfilled in the xml.

The LogoutResponse is not empty.


Regards

Hi Telmo,

Could you or someone else from the team check this issue quickly?
We are now on production with a Go Live planned for early next week and the current situation will not be acceptable for our customer.

Thanks for your support.
Greg


Hi
You'll need to debug to check the error in more detail, namely debug IdP to check the logoutresponse and go step by step to check on which moment the flow goes into a unwanted direction. Since you are in IdP mobile with device browser, you'll need to check in the debug if the flow finish sending the browser to the deep link and on which moment it goes to another direction.


Regards

Telmo Martins wrote:

Hi
You'll need to debug to check the error in more detail, namely debug IdP to check the logoutresponse and go step by step to check on which moment the flow goes into a unwanted direction. Since you are in IdP mobile with device browser, you'll need to check in the debug if the flow finish sending the browser to the deep link and on which moment it goes to another direction.


Regards

Hi Martins,

we have debugged some more and found out that at "DoSLOLogout" screen of the IDP module the flow doesn't find a sessionIndex during the preparation. This results in the opening of the OrignalURL as this is an input param.

But this URL points to https://"mydomain"/idp/actionIdP_SingleLogout_URL. Which has been set in this function itself. This seems to be odd behavior because this URL will always fail.

So my conclusion is that at the point of creating the deeplink with the action IdP_SingleLogout_URL, something is not set correctly. So that whenever the logout flow doesn't run correctly (like not finding the session), the app is redirected to this incorrect URL.

Furthermore this not finding the session seems to be an underlying more important issues.
This is triggered by closing the app without loging in. If you reopen the app, you are still loged into outsystems, but the session doesn't know the correct session variables to succesfully log out.

Can you have a look at this behaviour? This is all within the default modules of IdP
Can we have a call around this? To further explain what we have discoverd.

Kind regards,

Hi,

From what you described it seem that the IdP component session in the device browser already expired which explains all that behavior.

It's not a bullet prof workaround but it should overcome that issue (the idp server session may still be active on the device browser after this process). So can you try to do the following changes on the IdP component (screen preparation of DoSLOLogout):

- Between If widget "No SessionIndex?" and "Logout" widget (when the If evaluates to True), add a new If widget with the condition FromMobile. If False then goes to the existing ExternalURL widget; if True then call the action "Mobile_ExitInAppUrl", then call a ExternalURL with the URL of the previous action call.


Then on MobileCloseInAppPoint screen preparation, on the switch Otherwise flow, call the action "GenerateDeepLink" and redirect the browser to it on the same way that it's already there. However since in this scenario we are unable to retrieve the sessionindex (and therefor is not possible to determine to which screen and module the deep link should call), you need to set a pre-defined Module and Screen input parameters to that call

(if you have more that one mobile app having this issues and also using IdP mobile with device browser, then you need additional customization to check which Module and Screen should be set as input).


Regards.

Telmo Martins wrote:

Hi,

From what you described it seem that the IdP component session in the device browser already expired which explains all that behavior.

It's not a bullet prof workaround but it should overcome that issue (the idp server session may still be active on the device browser after this process). So can you try to do the following changes on the IdP component (screen preparation of DoSLOLogout):

- Between If widget "No SessionIndex?" and "Logout" widget (when the If evaluates to True), add a new If widget with the condition FromMobile. If False then goes to the existing ExternalURL widget; if True then call the action "Mobile_ExitInAppUrl", then call a ExternalURL with the URL of the previous action call.


Then on MobileCloseInAppPoint screen preparation, on the switch Otherwise flow, call the action "GenerateDeepLink" and redirect the browser to it on the same way that it's already there. However since in this scenario we are unable to retrieve the sessionindex (and therefor is not possible to determine to which screen and module the deep link should call), you need to set a pre-defined Module and Screen input parameters to that call

(if you have more that one mobile app having this issues and also using IdP mobile with device browser, then you need additional customization to check which Module and Screen should be set as input).


Regards.

Hi Martins,

I tried your steps but without success. When I press the logout button. The user is logged out on Azure AD, his session is killed on IdP but he doesn't get redirected to the application and because of that he remains logged in on OutSystems.

Also in your second part you tell me to add the "GenerateDeepLink" to the Otherwise flow. But on this Otherwise flow we don't have the token. But "GenerateDeepLink" still requires a token?

Best Regards,


Hi,

Set the Token input as "" (empty text). It will still generate fine the deep link.

If you are still having issues, you need to repeat the debug process again to check where the execution flow goes on the wrong direction.

Regards.

Hi Martins,

We are still having the issue. Is there maybe something different we can check or change to fix this? Is it maybe possible to have a screenshare call (Skype) on Monday 15/07? Because it looks like we are getting stuck.


Best Regards,

Hi,

In that case you'll need to star over again to check the root cause (ie, try to debug and check what's going on).

Meanwhile was testing the scenario described above, ie, do a login then the session expires on IdP in the system browser and try to logout from the app with system browser. By default we got an error and we are not logged out from the mobile app, but with the changes that I mentioned I successfully was logged out from the mobile app:

 


Regards.

Telmo Martins wrote:

Hi,

In that case you'll need to star over again to check the root cause (ie, try to debug and check what's going on).

Meanwhile was testing the scenario described above, ie, do a login then the session expires on IdP in the system browser and try to logout from the app with system browser. By default we got an error and we are not logged out from the mobile app, but with the changes that I mentioned I successfully was logged out from the mobile app:

 


Regards.

Hi Telmo,

We have added these changes to the IdP flow.

After some debugging, we may have found the cause of the issue. As long as we have the system browser open in the background the logout is working as designed, even if we close the app between the login and logout. 

When you close the app and the system browser while the user is logged in then the user will have to select the client certificate again and the redirect fails.

Is there a way to keep a session open in the system browser (Chrome in our case) even when the browser is closed?

Regards

Hi,

With mobile apps, usually when we want to persist the mobile app session (ie, keep the user logged in after closes the mobile app) and the user wants to do a logout, we don't use single logout though IdP server, we just logout locally the mobile app (using with system browser if the user logout immediately after login then the session may be still active for some minutes in the device browser).

The way to achieve what you mentioned, ie, kept the session active in the device browser after we close it, is to persist the Login on IdP component. However it's not advised at all to do that, since the session will expire in IdP server and it will stay active on IdP component for a long timeshould be the "owner" of the session time frame and not the SP client. Additionally there are session variables in the IdP component that will be empty in the scenario of a session restored by by the persistent cookie and will also cause the Single Logout to fail. (basically the IdP component should never persist the session).


Have in mind you scenario (and assuming we want the keep the user logged in if he/she closes the mobile app) would go for solution to just logout locally from the mobile app without interaction with the device browser.

If required, to avoid those sessions 'leaks' in the device browser (at least until they expired) would say to control in the mobile app itself (for instance with a javascript variable) if the user logged in on the current app execution or not, and if yes, logout as usual otherwise logout only locally from the mobile app. (and again, if the user meanwhile already closes the device browser the session is "already" expired in the device browser).


Regards.

PS - not sure exactly what your process to accept the client certificate implies but it seems that when the browser is closed the user needs to repeat that process again.