Multi Factor Authentication

[bschulz88]

Hi guys, 

i installed the MFA plugin correctly enabled the plugin and a test user .

After logout and login, nothin happens. I started investigation and found the problem, but i dont know how to solve it: 

the Problem is that the system automatically forwards me to the home age without redirecting to the mfa page where I have to scan the QR code. This is because I configured the redirection to service portal via the following system properties:

name: glide.entry.first.page.script
value: new SPEntryPage().getFirstPageURL()

name: glide.entry.page.script
value: new SPEntryPage().getLoginURL()

(i think this way is documented officially)

What can I do? Normally, if a user is enabled for MFA, the QR Code page has to be shown, the user has to scan it and then redirecting to homepage.

THANKS

[bschulz88]

Just get new information about this:

If I do the login over the service portal (e. g. <...>/sp/?id=landing) it doesnt work.
If I type in die URL <...>/login.do, it works.

Anyone an idea, why it is not working over service portal login or where i can see what happens with login.do?

[MGanon]

Does this authentication process work for the fulfiller portal?

[scottl]

In Orlando, the MFA is built into the login widget and works, but there is a major issue with it.   

First, It must be turned on in the properties of MFA.

Multifactor Authentication Properties > Enable Multi-factor authentication:
Yes|No

Second, on the user record there is a field called "Enable Multifactor Authentication" that needs to be true.

HOWEVER!

There is a huge bug, breaking the user experience of MFA, with URL redirects, rendering it useless in the portal. The MFA code that SN wrote only works for the use case of logging in, only if you came to the login page directly and not been redirected to the login page via a portal "deep link", like in an email.

The error is in the redirection code that redirects to "multi_factor_auth_setup_page.do" after login if you came into the portal via a secure url. And as it tries to redirect you to "multi_factor_auth_setup_page.do", it doesn't account for the portal segment of the URL, and the redirect fails and 404's due to the incorrect URL segment of it including the portal segment.  Now if the user drops out of the MFA process half way, and comes back again via another secure url, it continues to redirect to a missing page (404) because of the malformed URL.

Example.

Inward secure url
...servicenow.com/sp/?id=some_secure_page

> Login
...servicenow.com/sp/?id=login

Redirects to 404 as no page exists on that URL due to the included portal segment.
...servicenow.com/sp/multi_factor_auth_setup_page.do


The fix is that the redirect needs to consider that the portal is part of the URL segments, and needs to be removed in-order to point to the correct UI Page of "multi_factor_auth_setup_page.do"

Corrected URL for redirect.
...servicenow.com/multi_factor_auth_setup_page.do

The bug is that the redirect script is missing the forward slash for the relative link. eg...
$window.location = "/multi_factor_auth_setup_page.do";

But can I find the code anywhere where I can change it, nope. And thus rendering the MFA through the portal broken because if it doesn't redirect correctly, and to 404 pages that the end user cannot break free from due to the incomplete MFA process, it's essentially breaks the portal.

I have tried multiple work arounds but to no avail as the login widget response doesn't go far enough in it's login process and response to create a condition to test aganist. And this issue exists outside of the login process too, if failure to complete the MFA process happened, and so the only way to resolve it was at the redirection point. But it seems that code sits somewhere on the inside of SN.

Now this might only be related to this customers instance, but if anyone knows another work around, it'll be great to hear how you did it.

[bschulz88]

scottl, thanks for your answer.

i agreee, but this bug exists already in earlier versions i think. but thank you for the Reply.