Hey guys,
I think this topic is worth mentioning, as many of you will be moving (if not there already) to Jakarta and also many of you are using SSO authentication.
Here is my story - we have an internal multi SSO provider, meaning we have multiple identity providers for multiple servicenow instances (we have one idp servicing our prod instance, and another idp servicing our three non-production instances. We were running the SAML2 plugin where we had configured our external authentication. And we just recently upgraded to Jakarta.
So, how it all began was than after our upgrade, I tried to enable the mobile app for usage. Here is the first thing you should know - Mobile App works with external authentication (SSO) ONLY if MultiSSO plugin is enabled. It DOES not work if you have SAML2 enabled.
With this in mind, I went ahead and activated the MultiSSO plugin in our Dev instance. What it is supposed to do is - to replace the current SAML module, hide it, deactivate the properties and activate the new MultiSSO module with its new properties. It does that, plus gives you the options to configure multiple SSO IDPs, which I have to admit is helpful.
However, what it does not do is fully take care of the properties side, which might lead to you being unable to log to your instance using SSO, but instead you are trapped in a 'user does not exist' trap. Also what could be worse if you have some redirection script (like we did) for your service portal - it is related to your SSO configuration, so you have to think of that!
To escape falling in that trap:
- (optional - depending on do you have a redirection script or not) Deactivate the redirection script before we activate the MultiSSO plugin
- Enable the MultiSSO plugin.
- Disable the system property 'glide.authenticate.external' - set it to false (this is supposed to be done by the system, but unfortunately it is not).
- Enable the system property 'glide.authenticate.multisso.enabled' - verify it is set to true.
- Very, very important - something you need to verify is what is the field which the IDP and the ServiceNow instance will communicate over. With SAML2 there was just one option, and the default was user_name. Therefore there was no room for mistake. However, now with MultiSSO, you have a default field, and you have the option to specify a field for each IDP. Meaning you can get in the trap like me - our IDP was expecting the user_name, however the field on the IDP setting in MultiSSO module was set to 'email', which led to the system being unable to recognize the user.
Some tips I can give you given on my troubleshooting experience and the help from ServiceNow support:
Troubleshooting
a. Go check the logs, search for 'saml' and see the saml response xmls
b. Use some xml translator tool and see what this xml means for you = what is the dialogue which happens
Beware: Another bug, yes, I think it's a bug, we came upon was an UI action in the IDP form, when we tried to edit the User Field. When you edit the user field and try to Save/Update the form, you get a message that you need to Test the connection first. You click on the 'Test Connection' button, everything is OK, then you click 'Activate' again and.... same message. I feel the code behind the UI Action 'Activate' needs review, I hope the guys from ServiceNow will fix that. In the meantime, you can just deactivate the UI policy which prevents the 'active' field from being editable, and activate it manually as a workaround.
This is it. After some hours of troubleshooting and talking with ServiceNow support, now I have MultiSSO and I can use mobile app with external authentication.
Voila!:) Good luck to everyone!
