[IdP Mobile] Not getting "LoginResponse" using IdP Mobile

[IdP Mobile] Not getting "LoginResponse" using IdP Mobile

  
Forge Component
(2)
Published on 4 Jul by Telmo Martins
2 votes
Published on 4 Jul by Telmo Martins

Hi,

We already have IdP successfully configured and working for web applications but when we use the "IdP Mobile Sample" that utilizes the IdP Mobile, we are getting the following error:


So we went to the SAML Message Logs of the IdP Configuration page and we see that there is no LoginResponse row above each AuthnRequest made from the IdP Mobile.


And this is the Detail window of the AuthnRequest row underlined:



Thanks in advance,

Tomas.

Hi Tomas,

First of all the IdP server URL seems to be an URL not exposed on the 'public' web, so you have to make sure that you can access it from your mobile device network.

Then, if you have access you have to inspect you app on debug mode, and check where the error occurs as the errors logged on javascript console.

Regards

Hi Telmo,

Thanks for the quick response. I have used a company device (iPad) connected to the company network.

I tested browsing a web application where we have implemented the IdP and it's working properly so I guess we can discard issues with the network.

We may not be able to debug the mobile application using the company device due to company security restrictions.

Is there another way to troubleshoot this error?

Thanks!

Hi,

You can check if it's some issue opening that URL on the InApp browser. Please do the following test: on IdPMobile eSpace, SamlLogin WebBlock imports the InAppBrowser Webblock, on that import change the Target input parameter to Entities.Target.SYSTEM, then refresh all the stuff and check if the URL is opened (it will open it on the device default browser). If the URL is opened fine on that way, then would say that most probably for some reason that specific URL cannot be opened through the InAppBrowser pluggin, Usually the main reason for that issue it's due the IdP server certificate for that URL which is not fully compliant with the device/Operating System version 'standards', which are not related with the App itself but with the Operating System on your device.

Regards.

Hi Telmo,

I did what you said, so after clicking on the Login button it opened the Safari browser and it went to our ADFS and then went back to the following page:

https://exxonmobil-dev.outsystemsenterprise.com/IdP/__CLOSE_THIS_THING__

Is that URL the one we were looking for?


Thanks.  

Hi Tomas,

You should revert that Target input parameter, this was just a test to confirm that for some reason the InAppBrowser plugin cannot open that URL on that specific device, as you should to debug the app for further analysis.

Regards

Hi Telmo,

Yes, I am going to revert that change that I made to the input parameter.

So to fully understand and give it a closure, correct me if I am wrong, I need to debug the app to analyze what is going on because it isn't an Operating System issue, right?


Thanks for all the assistance.

Hi Tomas,

Yes, would say to debug for further analysis. However as I said before the InApp browser is very 'picky' regarding the URL and the SSL certificate that it uses and that also depends on the Operating System version on the device. Most probably with another device with other version of Android/IOS it will open it. 

In your case may or not may be related with this. From what I already saw in a few similar situations, the user access with another device which operating system has less restricted policies for the InApp browser, or the Idp server replaces the SSL certificate to be compliant and not cause such issues.

If you are able to debug, through the javascript console you can put commands to open any URL through the InApp and check how it goes for each one, and if it's only that one.

Regards

Hi Telmo,

I will debug the application and try to fix the issue. I'll let you know what I find.


Thanks.

Solution

Hi Telmo,

I found what was the issue. The InAppBrowser wasn't even reaching our internal URL because it wasn't using our VPN. Now it is going throug our VPN and it's working as expected.

Therefore, it was a connection issue from the beginning, sorry for the inconvenience.


Regards.

Solution