How to set up Single Sign-On for Targetprocess with ADFS 2.0
Step-by-step guide on how to set up Single sign-on integration with AD FS 2.0 on Windows Server 2012 R2
Targetprocess supports most of the SAML 2.0 compatible providers including OneLogin, Okta, AD FS 2.0/3.0, Azure AD, Google Apps, Bitium, Centrify and PingIdentity.
This guide covers SAML 2.0 SSO setup using Windows Server 2012R2 Standard with AD FS 2.0 serving as Identity Provider.
Windows Server 2008 R2 supports AD FS 2.0, Windows Server 2012 supports AD FS 2.1, Windows Server 2012 R2 supports AD FS 3.0. Targetprocess SSO setup with AD FS 2.0 covered in this guide
The connection between ADFS and Targetprocess is defined using a Relying Party Trust (RPT). Select the Relying Party Trusts folder from AD FS Management. and add a new Standard Relying Party Trust from the Actions sidebar. This starts the configuration wizard for a new trust.
On the welcome screen, press Start.
Select Data Source
Select "Enter data about the relying party manually"
Specify Display Name
Enter Name, e.g. “Targetprocess”
Select “AD FS Profile”
Skip token encryption certificate step, it’s not supported by Targetprocess SSO
Now you need to log in as administrator to your Targetprocess account and get out your “Single sign on URL” for AD FS. In Targetprocess its called “Assertion Consumer URL” and can be found at Settings > Authentication and Security > Single Sign-On.
Copy it and paste in AD FS wizard as “Relying party SAML 2.0 SSO service URL”
Enter your Targetprocess URL as “Relying party trust identifier”, e.g. “https://your_account.tpondemand.com”
Do NOT add slash "/" at the end of identifier, otherwise integration won't work.
Choose Issuance Authorization Rules
Select initial behavior for the authorization rules.
Select “Permit all users..” if you want to allow all Active Directory users to login to Targetprocess or “Deny all..” if you want to allow specific users later.
To change the behavior further, select the relying party trust and click Edit Claim Rules in the Actions pane.
Advanced rules can be configured later: Create a Rule to Permit or Deny Users Based on an Incoming Claim.
With “Permit all users” rule selected and “Enable JIT provisioning” Targetprocess SSO setting enabled your users may quickly consume all available Targetprocess licenses. Therefore we recommend to not enable these two options simultaneously.
Ready to Add Trust
Don’t change anything on the next step
Select “Open the Edit Claim rules..”
Click ‘Add’ on Claim rules wizard and keep “Select LDAP Attributes as Claims” on first step
For Targetprocess versions below 3.10.0
Add “Email” rule with E-Mail Address claim and Active Directory as attribute store
For Targetprocess versions 3.10.0 and above
Add (or edit existing rule in case of update) “Email” rule with E-Mail Address claim and Active Directory as attribute store, note "E-Mail Address" outgoing claim type
Then add second rule, this time choosing "Transform an Incoming Claim"
Use following settings for rule:
You will end up with two rules (note the order, "Email - E-Mail Address" rule must be first)
Next steps are common for all Targetprocess versions.
Open Targetprocess application > Settings.
To find out your Sign-On URL download and open a metadata file from your AD FS server via https://server.mydomain/FederationMetadata/2007-06/FederationMetadata.xml and check for SingleSignOn Location. In following example the URL is https://adfs.tpondemand.com/adfs/ls/ (Important: when copying the link make sure you grab it with the slash in the end)
Next we need to find out our signing certificate we are using on AD FS server. Open AD FS > Certificates. Right click on Token-signing certificate, open Details tab and click on Copy to File.
In wizard select “Base-64 encoded X.509” option
After exporting the certificate to file open the file with Notepad or other text editor, copy all text and paste to “Certificate” field in Targetprocess SSO settings.
The Federation Server is usually not directly accessible from the Internet, so you need to set up a proxy. Here’s additional information about proxy setup:
AD FS 2.0 installer for Windows Server 2008 R2
Please use our main guide to find information about possible problems.Besides that for AD FS -based SSO it's recommended to always check AD FS log in Windows event viewer to locate error details. Example of error caused by incorrect party identifier: