S
erviceNow makes configuring SSO into your ServiceNow instance very simple. By enabling a plugin and configuring a couple of properties, single sign-on can be set up in less than 10 minutes. Documentation surrounding these SSO methods are also well done and easy to follow.
Recently, I’ve come across a number or clients that want to use ServiceNow as their main company portal and wish to configure their ServiceNow instance to generate an SSO token that can be consumed by a third party service provider. In other words, they desire to have outbound single sign-on directed to of their other internal applications. Because of this increasingly common request, I have created an update set that can be used for such a purpose called, Outbound Single Sign-on via Digested Token.
Once you’ve applied this update set, the outbound SSO is quite simple to configure. Refresh the application list to see a new module under the Self-Service application called Redirect POST / SSO . This will be the link that the end user will click on to launch the 3rd-party web application. You can change the name of this link to reflect the application you’re about to launch.
The following steps will need to be followed to configure this new functionality for your environment:
- Go to the UI pages module and edit the UI Page called SSO
- Modify the 4th line in the script to point to your web application
- var destURL = “https://your-web-app.com“;
- Go to the Single Sign-on module and go to the last property in the list. Set the secret passphrase to use for the digested token. This should match what your 3rd-party web app is using to generate its digested hash.
Once the above steps are complete, the ServiceNow instance will be ready to launch the 3rd party application and send it SSO tokens. If that application does not yet support digested token SSO, it will need to be configured to do so. Using this update set, ServiceNow will be sending your application the following as token POST parameters:
SM_USER=[username]
DE_USER=[digest]
The 3rd-party web app will need to take the user found in the SM_USER parameter and HMAC_SHA1 hash it with the shared secret to create the digest. The resulting digest should be compared to the digest sent in the DE_USER. If they match, then authenticate the user.
To help you on your way to writing code for your in-house application to create this hash, you’ll want to take a look at our digested token test utility to see what the has should be and PHP, C#, and Java examples on how to programmatically create it.
We were testing this out and found there is a conflict, well more of an update of your function generateDigest() that overlaps with the google_getLatLong(addr). Is there an update to this update set so these sys_id’s don’t conflict?