App crash when server SSL certificate is expired (Open ID Connect)

[cosmanovich]

We are using Open ID Connect and Authorization code grant type to authenticate our users.
When we try to connect to our test system which has an expired SSL certificate, an app crash occurs.

The call stack is:

2019-06-17 08:55:08.101 6209-6209/com.bmsvision.mymes E/AndroidRuntime: FATAL EXCEPTION: main
    Process: com.bmsvision.mymes, PID: 6209
    java.lang.NullPointerException: Attempt to invoke virtual method 'void org.apache.cordova.CallbackContext.error(org.json.JSONObject)' on a null object reference
        at oracle.idm.auth.plugin.IdmAuthenticationPlugin.invokeCallbackError(IdmAuthenticationPlugin.java:175)
        at oracle.idm.auth.plugin.IdmAuthentication.onAuthenticationChallenge(IdmAuthentication.java:433)
        at oracle.idm.mobile.OMMobileSecurityService$Setup1WaySSLCompletionHandler.createChallengeRequest(OMMobileSecurityService.java:967)
        at oracle.idm.mobile.OMMobileSecurityService$SetupTask.onPostExecute(OMMobileSecurityService.java:931)
        at oracle.idm.mobile.OMMobileSecurityService$SetupTask.onPostExecute(OMMobileSecurityService.java:895)
        at android.os.AsyncTask.finish(AsyncTask.java:695)
        at android.os.AsyncTask.access$600(AsyncTask.java:180)
        at android.os.AsyncTask$InternalHandler.handleMessage(AsyncTask.java:712)
        at android.os.Handler.dispatchMessage(Handler.java:106)
        at android.os.Looper.loop(Looper.java:193)
        at android.app.ActivityThread.main(ActivityThread.java:6746)
        at java.lang.reflect.Method.invoke(Native Method)
        at com.android.internal.os.RuntimeInit$MethodAndArgsCaller.run(RuntimeInit.java:493)
        at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:858)

I have looked where the problem occurs and this is what I found:

The method 'Setup' of the class 'IdmAuthentication', has the following code:

_ommss = new OMMobileSecurityService(_mainActivity, _props, this);
_ommss.setup();
_setupLatch.await();

if (_setupException != null)
{
      throw _setupException;
}

The code above creates an instance of 'SetupTask' and waits for it's completion.
The 'SetupTask' is executed and on completion a 'Setup1WaySSLCompletionHandler' is created and returned without calling 'sMSS.invokeSetupCompleteCallback' (see code snippet below). By not calling this method the await in the previous code snippet is never completed.

@Override
protected void onPostExecute(OMMobileSecurityException e) {
            if (e != null && e.getExceptionEvent() != null) {


                OMExceptionEvent event = e.getExceptionEvent();

                //lets check for SSL events
                if (event instanceof SSLExceptionEvent) {

                    SSLExceptionEvent sslEvent = (SSLExceptionEvent) event;

                    OMAuthenticationChallenge sslChallenge = new OMAuthenticationChallenge(OMAuthenticationChallengeType.UNTRUSTED_SERVER_CERTIFICATE);
                    sslChallenge.addChallengeField(OMSecurityConstants.Challenge
                            .UNTRUSTED_SERVER_CERTIFICATE_AUTH_TYPE_KEY, sslEvent.getAuthType());
                    sslChallenge.addChallengeField(OMSecurityConstants.Challenge
                            .UNTRUSTED_SERVER_CERTIFICATE_CHAIN_KEY, sslEvent.getCertificateChain());
                    new Setup1WaySSLCompletionHandler(sMSS.getMobileSecurityConfig(), sMSS.getCallback()).createChallengeRequest(sMSS, sslChallenge, null);
                    //handle 1-way SSL
                    return;
                } else if (event instanceof CBAExceptionEvent) {
                    //handle CBA
                }
            }
            sMSS.invokeSetupCompleteCallback(e);
}

The code from 'Setup1WaySSLCompletionHandler' causes the 'IdmAuthentication.onAuthenticationChallenge' method to be called. In the switch the case 'UNTRUSTED_SERVER_CERTIFICATE' is executed, this is were the exception occurs (and causes the app crash). The following code snippet contains the few changes I needed to do, to fix the issue:

case UNTRUSTED_SERVER_CERTIFICATE:
        _finishWebView();
        //IdmAuthenticationPlugin.invokeCallbackError(_loginCallback, PluginErrorCodes.UNTRUSTED_CHALLENGE);
        _ommss.getCallback().onSetupCompleted(null, null, new OMMobileSecurityException(OMErrorCode.SERVER_CERTIFICATE_NOT_ALLOWED));

        break;

• Comment out the 'invokeCallbackError', because _loginCallback is still null during setup
• Call the 'onSetupCompleted' method, because this calls '_setupLatch.countDown();', whichs causes the await in the first code snippet to complete. (and returns the error to the user).

These changes work in our situation, but I don't know if these changes influence other authentication flows. What would be the best way to solve this?

[anandvnath]

The issue is that plugin is not handling the untrusted server cert challenge as of now. I was not aware that this can happen while init as well. The real solution is to implement the challenge, so that user can decide if he wants to proceed with the untrusted server or not. This is in my TODO list.

The argument we did not implement untrusted server challenge and one other challenge in the first place on priority is that a proper environment will not face this issue and is only an issue in dev / test envs. But in those envs as well, a certificate can be generated and used.

[cosmanovich]

The issue is that plugin is not handling the untrusted server cert challenge as of now. I was not aware that this can happen while init as well

I think this is because the OpenID configuration is being requested from the server while initializing. But I'm not sure.

The argument we did not implement untrusted server challenge and one other challenge in the first place on priority is that a proper environment will not face this issue and is only an issue in dev / test envs. But in those envs as well, a certificate can be generated and used.

I completely understand why this was not implemented and this is indeed an issue that will only occur in test environments.

But it would be better if the app doesn't crash in this scenario.
It's kind of sad when you're trying to give a demo and the app crashes, while you're trying to connect to a demo system. 😜
Just returning an error would be good.

[anandvnath]

True. Will try to fix in next release.