Prevent re-authentication after changing URL (using custom instance URL)

Joe B2 · ‎07-28-2022

Afternoon,

I'm hoping someone can help/point me in the right direction for this.

We are in the process of splitting out our portal as a part of our company is moving to another in the same group. To aid in this we have setup a custom URL to be used on the other portal. This is all being done without domain separation.

A number of our users will have the ability to use both portals and will use the same login account for this. However the location portion of the URL needs to change completely and not just the portal suffix when moving between portals. E.G instead of:

https://dev.servicenow-com/csm to https://dev.servicenow-com/hcp

we need:

https://dev.servicenow-com/csm to https://portal.someotherdomain/hcp

Whilst doable this requires the user to re-authenticate which we really want to avoid. We have a mix of SSO and local login users depending on the customer and then SSO uses different IDP's dependent on the customer as well.

Is there a way to let SN know that the user has already been authenticated for this session so doesn't need to login again, no matter the URL?

Thank you for any help you can offer.

Joe B2 · ‎07-25-2023

Just replying to this old post to close it off.

I didn't find an acceptable way around this in the end. This is less about ServiceNow and more about how browsers work I think. When swapping from https://domain1/csm to https://domain2/hr the browser has no knowledge of a login to that second domain.

It is technically possible to do the following but I would strongly advise against it. We decided it sounded too much like one of those cautionary tales of security gone wrong you hear.

It is possible to pass a username and password in the URL parameter to get the user logged in. You could, in theory, setup a transfer widget that sets a local password for the SSO user, pass it and the userID into the URL (password is visible to the user in the URL). This will auto login the user and you can then change the password again to prevent re-use.

In the end though we opted to use the same domain for all SSO users and anyone else has to login again as this is best for security.

View solution in original post

Allen Andreas · ‎07-28-2022

Hello,

ServiceNow, in theory, would already know that.

Is the user presented with a different login widget at the other URL? If there's another IDP set for that login widget, for example, then the authentication will be triggered if they aren't already logged in.

Can you give a bit more information as to the test scenarios where you're seeing that they need to login and more information along the lines of if those users would have been authenticated with the same IDP on some other page?

Please mark reply as Helpful/Correct, if applicable. Thanks!

Please consider marking my reply as Helpful and/or Accept Solution, if applicable. Thanks!

Joe B2 · ‎07-28-2022

Afternoon Allen,

Thank you for responding.

The different portals both use the same login page and widget. In this instance I am using a local login account and do the following:

Access either of the URLs (https://dev.servicenow-com/csm or https://portal.someotherdomain/hcp)
Login as normal and get routed to the relevant portal page
Attempt to access the other URL. This is either via an inbuilt button in the portal or by directly typing the URL into the window.

When doing this the user is presented with the login window on the other portal as if the user isn't authenticated.

I have cloned the widget and confirmed that the value of gs.getSession().isLoggedIn() is false when swapping between portal URLs.

This explains why the page is showing but not why it is false and how to get around it.

In this instance the user is a local account so shouldn't have any SSO and IDP issues.

Joe B2 · ‎07-28-2022

Afternoon Allen,

Thank you for responding.

The different portals both use the same login page and widget. In this instance I am using a local login account and do the following:

Access either of the URLs (https://dev.servicenow-com/csm or https://portal.someotherdomain/hcp)
Login as normal and get routed to the relevant portal page
Attempt to access the other URL. This is either via an inbuilt button in the portal or by directly typing the URL into the window.

When doing this the user is presented with the login window on the other portal as if the user isn't authenticated. I would need to clone the login widget (to add some log lines) to test this but am assuming is believes the value of gs.getSession().isLoggedIn() is false.

In this instance the user is a local account so shouldn't have any SSO and IDP issues.

Joe B2 · ‎07-28-2022

As a note. I have cloned the widget and confirmed that the value of gs.getSession().isLoggedIn() is false when swapping between portal URLs.

This explains why the page is showing but not why it is false and how to get around it.