After switching from user id to email as a key for our sso idp, default cannot be selected.

[Rain Vaine]

Hello experts,

We are having problems with our sso authentication using the user_id field as our key that is why we switched to using the email field instead. But after creating this IDP record that now uses the email field, default button cannot be selected and we thrown with an error like this:
Error accessing descriptor for metaObject: package_private script include function MultiSSOLogin: no thrown error com.glide.ui.ServletErrorListener
When I examined the history of the record given to us, it seems that it didn't even connect properly. Is my assumption correct that the IDP didn't connect properly based on the history of the record?

Do you have any recommendation on what other factors do we need to check?

Regards

[Michael Jones - · Accepted solution]

After you create the new IDP record, were. you able to complete a successful test with the "Test Connection" UI Action? The IDP record will need to be tested and active before it can us utilized. 

In addition, if you have multiple IDP records, only one can be set as default. If another record is currently the default, you may need to first clear any value in the "glide.authenticate.sso.redirect.idp" system property, or manually set the value of this property to the sys_id of the IDP you record created. 

[Rain Vaine]

Hello,

Thanks for the reply, I already found the reason why the "Test Connection" UI Action was set to false since they made it using the sys property glide.authenticate.multisso.test.connection.mandatory with the value as false and you can activate the idp without the test connection. as per stated from the documentations below:

 https://docs.servicenow.com/en-US/bundle/tokyo-platform-security/page/integrate/single-sign-on/task/....

That is why it is troubling why default can't be set even though there is no other default idp record set.

Regards

[Rain Vaine]

Hello,
By the way when i checked the properties this one glide.authenticate.sso.redirect.idp is not present for our instance.

Regards