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

[Joe B2]

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 · Accepted solution]

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.