ADFS: ADFS 4.0 (Win Server 2016)
SN: Orlando (Patch 3, 7 May 2020)
Hello,
Hopefully this might help someone and I of course hope that this will also help me to get our SSO working with ADFS 4.0.
This is quite a long post and was a while since I integrated something with ADFS and extremely new with SN so bear with me if I have misunderstood something or configured something wrong.
I have followed these instructions from SN here for ADFS:
https://docs.servicenow.com/bundle/orlando-platform-administration/page/integrate/saml/concept/c_ADFSIntegrationWithSAML2.0.html
which under this step - "Set up the instance for ADFS" - directs you to the section - " Authentication with SAML".
After the setup when it didn't work I "found out" that if I go to:
Multi-Provider SSO > Identity Providers > New > SAML
I am able to provide either an URL or an XML containing the IdP metadata (ADFS in my case) and did so this time to write down my procedure.
It would also be the easiest way IMHO to configure IdP instead of having to manually parse the fields which the documentation suggest so if a more straightforward official guide to configure SSO could use this method from start to finish I would appreciate it.
I might also do something completely bonkers and miss something and if so please disregard the comment above 😄
Steps:
1)
Installed "Integration - Multiple Provider Single Sign-On Installer"
2)
Multi-Provider SSO > Identity Providers > New > SAML > URL > URL: https://adfs.mydomain.com/FederationMetadata/2007-06/FederationMetadata.xml
3)
Set it to "Default" and fields are prepopulated from the federation metadata as such (see printscreen)
Now the certificates are prepopulated with two certificates and both have SHA256 as their algorithm so I guess I need to change:
"Secure Signature Algorithm"
from
http://www.w3.org/2000/09/xmldsig#rsa-sha1
to
http://www.w3.org/2001/04/xmldsig-more#rsa-sha256
? (Also see step 6)
Anyway I did that and pressed "Update" > "Generate metadata" (saved this temporarily)
4)
Following these instructions - "Configure an ADFS relying party":
https://docs.servicenow.com/bundle/orlando-platform-administration/page/integrate/saml/task/t_ConfigureADFSRelyingParty.html
On our ADFS-server:
AD FS > Relying Party Trusts > Add Relying Party Trust
"Claims Aware" > [Start]
"Import data about the relying party trust from a file" > [browsed to test.xml where I saved the generated metadata from SN] > [Next]
"Display Name" > [entered "ServiceNow - Dev"] > [Next]
"Permit everyone" highlighted > [Next]
"Ready to Add Trust" (everything is greyed out) > [Next]
Deselected "Configure claims issuance policy for this application" > [Close]
Selecting "ServiceNow -Dev" > "Properties" in the list for "Relying Party Trusts"
"Advanced" > "Secure hash algorithm" is "SHA-256" as I changed in SN, OK.
"Endpoints" (these fields are already prepopulated for me):
Endpoint type: SAML Assertion Consumer
Binding: POST
Index: 0
Trusted URL: https://<my-dev-instance-id>.service-now.com/navpage.do
Endpoint type: SAML Assertion Consumer
Binding: POST
Index: 1
Trusted URL: https://<my-dev-instance-id>.service-now.com/consumer.do
Endpoint type: SAML Logout
Binding: POST
Trusted URL: https://<my-dev-instance-id>.service-now.com/navpage.do
5) Following these instructions here exactly as-is, nothing not described there - "Configure ADFS relying party claim rules":
https://docs.servicenow.com/bundle/orlando-platform-administration/page/integrate/saml/task/t_ConfigureADFSClaimRules.html
6) Now these instructions here:
https://docs.servicenow.com/bundle/orlando-platform-administration/page/integrate/saml/task/t_CreateASAMLLogoutEndpoint.html
mention to create a new "SAML Logout" endpoint but I found out this post:
https://community.servicenow.com/community?id=community_article&sys_id=8ff4a46cdb06374014d6fb2439961918
(A shoutout and thanks to
where he explicitly says NOT to do that and that the information is wrong, so I didn't do it.
7) Eh *scratching head* OK so a lot of the official documentation seem to require you to google (more then usual) and to combine the official documention (but not all parts!) to forum-posts by helpful members.
In SN:
Multi-Provider SSO > Administration > x509 Certificates > SAML 2.0 Keystore_Key2048_SHA256 > [Toggled / Checked "Active"] > [Needed to select "Me" as notifier even though the "cert" doesn't expire] > [Update]
Aaaand thats when I just realised that I probably need to make these changes (step 6 and forward) before generating the metadata in SN and adding it to ADFS.....
I'll continue updating this tomorrow, hopefully when its done I can do a writeup for setting up ADFS start to finish.
If you see any errors I make please point them out, I am very grateful for that 🙂
Best Regards - Karl
Thank you for your reply,
Was FINALLY able to get this far at least:
Now I totally admit it was a while since I set up a service against our ADFS but I NEVER have experienced these amount of problems and needing to use parts of the official documentation combined with third-party content such as blogs and forum posts to be able to sort it out. The worst part is that it is still not sorted.
ADFS isn't exactly an obscure IdP so having a COMPLETE guide from A to Z regarding the setup isn't to much to ask unless the whole idea is to need to hire external consultants for a lot of $$$.
Rant finished and ofc not directed to you but having sat and trying to get this sorted a fine Saturday makes me a bit irritated.
I went and redid the entire thing, wiped my instance and started from scratched and used the "ITSM Guided Setup" instead.
Naturally then I ran into a problem at the get-go:
"Add New IdP" > "IdP Metadata URL"
Either entering the URL for our FederationMetadata or entering the XML itself fails with an helpful errormessage of "There was an error parsing the response".
This works fine if I set it up using:
"Multi-Provider SSO" > "Identity Providers" > "New" > "SAML" > "URL"
So I parsed the FederationMetadata using this tool:
https://adfshelp.microsoft.com/MetadataExplorer/GetFederationMetadata
and also parsed the XML returned in itself using:
https://jsonformatter.org/xml-parser
Here are my settings under:
"Multi-Provider SSO" > "Identity Providers"
Fields that are doesn't show its actual value below:
"Signing/Encryption Key Password" = "saml2sp"
"Secure Signature Algorithm" = "http://www.w3.org/2001/04/xmldsig-more#rsa-sha256"
"Protocol Binding for the IDP's AuthnRequest" = "urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect"
"Protocol Binding for the IDP's SingleLogoutRequest" = "urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect"
I read nowhere about this step which was required:
"X.509 Certificate" > "SAML 2.0 Keystore_Key2048_SHA256" > "Active"
^ Set yourself ("System Administrator") to notify on expiration since it is required
Copy the "sys_id" found in your browsers URL-bar when being on that certificate, it is URL encoded and looks something like this:
URL-encoded: sys_id%3D3685fc22930212003c5537ae867ffb91%26
URL-decoded: sys_id=3685fc22930212003c5537ae867ffb91& ("%26" being the character "&")
We want the value between "sys_id=" and the last "&" = 3685fc22930212003c5537ae867ffb91
In the navigation filter enter "sys_properties.list" > [Enter]
Search for "glide.authenticate.sso.saml2.keystore" and set the "Value" of this to the "sysid" of "SAML 2.0 Keystore_Key2048_SHA256"
Ex:
Value: 3685fc22930212003c5537ae867ffb91 > [Update]
So whats the issue now?
ADFS-portal > Logging in > Selecting "ServiceNow - Dev" > Getting directed to "https://<myinstance>.service-now.com/navpage.do" without getting logged in.
No errors in EventViewer / ADFS. *sigh*
Edit:
Sorry, for some reason I was able to see the uploaded images but when checking it in an "incognito"-session the images appeared to be broken. Corrected this.
Update:
In ADFS (where "myinstance" is the id of my devinstance):
Endpoints >SAML Assertion Consumer Endpoints:
URL: https://myinstance.service-now.com/navpage.do
Binding: Redirect
Index: 0
Default: Yes
URL: https://myinstance.service-now.com/consumer.do
Binding: Redirect
^ Post
Index: 1
Default: No
Endpoints >SAML Logout Endpoints:
URL: https://myinstance.service-now.com/navpage.do
Binding: Redirect
Index: 0
Default: No
Signature:
<I can see the cert here which would be the cert activated from SN for SHA-256 to sign requests>
Advanced:
Secure Hash Algorithm: SHA-256
Edit Claim Issuance Policy >
"Get LDAP Attributes" (Rule - Send LDAP Attributes as Claim):
Attribute Store: Active Directory
LDAP Attribute: E-Mail-Addresses
Outgoing Claim: E-Mail-Addresses
"Email to Name ID" (Rule - Transform an Incoming Claim):
Incoming Claim Type: E-Mail Addresses
Outgoing Claim Type: Name ID
Outgoing Name ID Format: Email
Pass through all claim values: Enabled / Checked
Update (again):
Think I got this working, I changed (in ADFS) the "SAML Consumer Assertion Endpoint" of "navpage.do" from "Redirect" to "Post" but what actually did it was to enable:
"Enable multiple provider SSO" in either
"Multi-Provider SSO" > "Administration" > "Properties"
or through the "ITSM Guided Setup" (see attached printscreen):
Now under the the specific IdP in ServiceNow I set it to:
Enabled
Primary
Default
To need to toggle "Enable multiple provider SSO" as well in addition to all those options kinda... makes no sense?
I get that "Enabled" makes the IdP enabled, primary causes it to be the primary of multiple possible IdPs configured but surely having it enabled and set to default and/or primary should dictate that it is indeed activated?
If this indeed is working I probably to a cleanup of all my working settings and configuration and possibly if they are interested submit them to SN so they can have a complete guide for ADFS 4.0 (YMMV).
Thank you for your reply.
Was FINALLY able to get this far at least:
Now I totally admit it was a while since I set up a service against our ADFS but I NEVER have experienced these amount of problems and needing to use parts of the official documentation combined with third-party content such as blogs and forum posts to be able to sort it out. The worst part is that it is still not sorted.
ADFS isn't exactly an obscure IdP so having a COMPLETE guide from A to Z regarding the setup isn't to much to ask unless the whole idea is to need to hire external consultants for a lot of $$$.
Rant finished and ofc not directed to you but having sat and trying to get this sorted a fine Saturday makes me a bit irritated.
I went and redid the entire thing, wiped my instance and started from scratched and used the "ITSM Guided Setup" instead.
Naturally then I ran into a problem at the get-go:
"Add New IdP" > "IdP Metadata URL"
Either entering the URL for our FederationMetadata or entering the XML itself fails with an helpful errormessage of "There was an error parsing the response".
This works fine if I set it up using:
"Multi-Provider SSO" > "Identity Providers" > "New" > "SAML" > "URL"
So I parsed the FederationMetadata using this tool:
https://adfshelp.microsoft.com/MetadataExplorer/GetFederationMetadata
and also parsed the XML returned in itself using:
https://jsonformatter.org/xml-parser
Here are my settings under:
"Multi-Provider SSO" > "Identity Providers"
Fields that are doesn't show its actual value below:
"Signing/Encryption Key Password" = "saml2sp"
"Secure Signature Algorithm" = "http://www.w3.org/2001/04/xmldsig-more#rsa-sha256"
"Protocol Binding for the IDP's AuthnRequest" = "urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect"
"Protocol Binding for the IDP's SingleLogoutRequest" = "urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect"
I read nowhere about this step which was required:
"X.509 Certificate" > "SAML 2.0 Keystore_Key2048_SHA256" > "Active"
^ Set yourself ("System Administrator") to notify on expiration since it is required
Copy the "sys_id" found in your browsers URL-bar when being on that certificate, it is URL encoded and looks something like this:
URL-encoded: sys_id%3D3685fc22930212003c5537ae867ffb91%26
URL-decoded: sys_id=3685fc22930212003c5537ae867ffb91& ("%26" being the character "&")
We want the value between "sys_id=" and the last "&" = 3685fc22930212003c5537ae867ffb91
In the navigation filter enter "sys_properties.list" > [Enter]
Search for "glide.authenticate.sso.saml2.keystore" and set the "Value" of this to the "sysid" of "SAML 2.0 Keystore_Key2048_SHA256"
Value: 3685fc22930212003c5537ae867ffb91 > [Update]
So whats the issue now?
ADFS-portal > Logging in > Selecting "ServiceNow - Dev" > Getting directed to "https://<myinstance>.service-now.com/navpage.do" without getting logged in.
No errors in EventViewer / ADFS. *sigh*
Thank you for your reply,
Was FINALLY able to get this far at least:
Now I totally admit it was a while since I set up a service against our ADFS but I NEVER have experienced these amount of problems and needing to use parts of the official documentation combined with third-party content such as blogs and forum posts to be able to sort it out. The worst part is that it is still not sorted.
ADFS isn't exactly an obscure IdP so having a COMPLETE guide from A to Z regarding the setup isn't to much to ask unless the whole idea is to need to hire external consultants for a lot of $$$.
Rant finished and ofc not directed to you but having sat and trying to get this sorted a fine Saturday makes me a bit irritated.
I went and redid the entire thing, wiped my instance and started from scratched and used the "ITSM Guided Setup" instead.
Naturally then I ran into a problem at the get-go:
"Add New IdP" > "IdP Metadata URL"
Either entering the URL for our FederationMetadata or entering the XML itself fails with an helpful errormessage of "There was an error parsing the response".
This works fine if I set it up using:
"Multi-Provider SSO" > "Identity Providers" > "New" > "SAML" > "URL"
So I parsed the FederationMetadata using this tool:
https://adfshelp.microsoft.com/MetadataExplorer/GetFederationMetadata
and also parsed the XML returned in itself using:
https://jsonformatter.org/xml-parser
Here are my settings under:
"Multi-Provider SSO" > "Identity Providers"
Fields that are doesn't show its actual value below:
"Signing/Encryption Key Password" = "saml2sp"
"Secure Signature Algorithm" = "http://www.w3.org/2001/04/xmldsig-more#rsa-sha256"
"Protocol Binding for the IDP's AuthnRequest" = "urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect"
"Protocol Binding for the IDP's SingleLogoutRequest" = "urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect"
I read nowhere about this step which was required:
"X.509 Certificate" > "SAML 2.0 Keystore_Key2048_SHA256" > "Active"
^ Set yourself ("System Administrator") to notify on expiration since it is required
Copy the "sys_id" found in your browsers URL-bar when being on that certificate, it is URL encoded and looks something like this:
URL-encoded: sys_id%3D3685fc22930212003c5537ae867ffb91%26
URL-decoded: sys_id=3685fc22930212003c5537ae867ffb91& ("%26" being the character "&")
We want the value between "sys_id=" and the last "&" = 3685fc22930212003c5537ae867ffb91
In the navigation filter enter "sys_properties.list" > [Enter]
Search for "glide.authenticate.sso.saml2.keystore" and set the "Value" of this to the "sysid" of "SAML 2.0 Keystore_Key2048_SHA256"
Ex:
Value: 3685fc22930212003c5537ae867ffb91 > [Update]
So whats the issue now?
ADFS-portal > Logging in > Selecting "ServiceNow - Dev" > Getting directed to "https://<myinstance>.service-now.com/navpage.do" without getting logged in.
No errors in EventViewer / ADFS. *sigh*
Edit:
Sorry, for some reason I was able to see the uploaded images but when checking it in an "incognito"-session the images appeared to be broken. Corrected this.
Update:
In ADFS (where "myinstance" is the id of my devinstance):
Endpoints >SAML Assertion Consumer Endpoints:
URL: https://myinstance.service-now.com/navpage.do
Binding: Redirect
Index: 0
Default: Yes
URL: https://myinstance.service-now.com/consumer.do
Binding: Redirect
^ Post
Index: 1
Default: No
Endpoints >SAML Logout Endpoints:
URL: https://myinstance.service-now.com/navpage.do
Binding: Redirect
Index: 0
Default: No
Signature:
<I can see the cert here which would be the cert activated from SN for SHA-256 to sign requests>
Advanced:
Secure Hash Algorithm: SHA-256
Edit Claim Issuance Policy >
"Get LDAP Attributes" (Rule - Send LDAP Attributes as Claim):
Attribute Store: Active Directory
LDAP Attribute: E-Mail-Addresses
Outgoing Claim: E-Mail-Addresses
"Email to Name ID" (Rule - Transform an Incoming Claim):
Incoming Claim Type: E-Mail Addresses
Outgoing Claim Type: Name ID
Outgoing Name ID Format: Email
Pass through all claim values: Enabled / Checked
Update (again):
Think I got this working, I changed (in ADFS) the "SAML Consumer Assertion Endpoint" of "navpage.do" from "Redirect" to "Post" but what actually did it was to enable:
"Enable multiple provider SSO" in either
"Multi-Provider SSO" > "Administration" > "Properties"
or through the "ITSM Guided Setup" (see attached printscreen):
Now under the the specific IdP in ServiceNow I set it to:
Enabled
Primary
Default
To need to toggle "Enable multiple provider SSO" as well in addition to all those options kinda... makes no sense?
I get that "Enabled" makes the IdP enabled, primary causes it to be the primary of multiple possible IdPs configured but surely having it enabled and set to default and/or primary should dictate that it is indeed activated?
If this indeed is working I probably to a cleanup of all my working settings and configuration and possibly if they are interested submit them to SN so they can have a complete guide for ADFS 4.0 (YMMV).
Hi,
I am facing some issue with this. I have SSO enabled and it is working in following way:
Users are getting login page first.
There is external login link in that page :
Once User clicks on external login link, he is supposed to enter userid. After entering userid, User is able to login to SN.
How to make User to directly login into SN, just by clicking SN URL? I am not sure from where this configuration needs to be done (ADFS side or SN).
