Internal vs External SSO not working properly

[ddaws]

We have recently setup SSO with adfs and were experiencing an issue getting the authentication to pass through. When visiting instance.service-now.com, it would take you to our adfs portal where you could put in your credentials. After you entered in your AD credentials, it would then take you back to servicenow as authenticated. However, we wanted to avoid any requirement for credentials from inside our network. Because you have already logged into your device, we believed entering credentials was unnecessary. We were finally able to solve this by changing the AuthenContextClassRef Method to "urn:federation:authentication:windows".

Our issue: By setting the method to what is above, we no longer have the ability to access the instance from outside of our network. This is also impacting mobile functionality. If you attempt to visit instance.service-now.com you can see the authentication attempt back to ADFS and you are then taken to the logout screen. I understand this makes sense because neither an external source nor a mobile source has the windows authentication taking place but we are at a loss on how to remedy the issue.

After doing research, it appears that one option would be to not define the method used and instead, disable the "Create AuthnContextClass" seen below:

However, the tool is not letting me disable this option. When I uncheck the box and click save, the check mark reappears. I have tried disabling the checkbox in the Advanced tab as well, however, clicking that location of the check box toggles the checkbox in the form but does not ever remove the check in the box under the advanced tab. Clicking save also reverts all check boxes back to checked.

Does anyone know why we are unable to disable this option and whether this solution would fix our issue?

Our desired result is:

Internal: SSO will verify the user and pass through windows authentication requiring no credentials.

External: SSO will attempt to verify the user, fail, and then present the user with the option of providing their ADFS credentials in order to proceed.

[ddaws]

After some additional research, it looks like this type of authentication doesn't use SAML. Since we want to use SAML, I believe my question has not slightly changed.

Using "urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport" how do we adjust ADFS or ServiceNow to allow authentication to be passed through when internal (and not require credentials) while not passing authentication when external (and requiring credentials)?

[ddaws]

I wanted to update this in case other's end up running into this issue.

I broke down and asked ServiceNow for some assistance. It turns out, we were on the right track the whole time and we needed to uncheck "create AuthnContextClass". As stated above, we were having an issue unchecking that box. Every time we unchecked and saved, the check returned.

It turns out, have the same check box on the form twice causes an issue. This is OOTB, keep in mind. Once we removed the field from under the "Advanced" tab, we were able to uncheck the box in the main area of the form, click save, and it would keep our setting. Once we did that, we removed all information from AuthenContextClassRef Method. This allows for ServiceNow and your SSO source to determine the necessary class that needs to be passed and everything worked exactly as it should. We now have pass through authentication working internally, and it prompts users for their ADFS credentials when logging in from outside our domain!

[smfoister]

Do you mind taking a a screenshot of your idp config page and redacting any security info? I'm having some trouble with this and would love to see what others have done.