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
- Single Sign-On
- How to set up Single Sign-On with Google G Suite (formerly Apps for Business )
- Single Sign-On in Targetprocess
- How to set up Single Sign-On in Targetprocess with Okta
- How to set up Single Sign-On with OneLogin
- How to set up Single Sign-On to Targetprocess with other SAML 2.0 Identity providers
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 2012 R2 standard (Windows Server 2008R2 supported as well but requires additional components setup )
- Active directory domain service installed
- Certificate (or self signed certificate for testing purposes)
- AD FS - Active Directory Federation Service role installed
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
Windows server configuration for Targetprocess SSO
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.
Targetprocess SSO configuration
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.
Testing SSO in Targetprocess
- Make sure your AD account is active and has non-empty E-mail address.
- Logout from Targetprocess (click on avatar picture and choose “Logout”)
- Open your Targetprocess URL in browser - https://YOUR_ACCOUNT.tpondemand.com/. Now two scenarios are possible:
- if you have disabled Targetprocess login form - browser will redirect you to AD FS login page and then to Targetprocess UI or you’ll be redirected to Targetprocess immediately.
- if you have mixed mode enabled - you’ll have to to click “Log in using Single sign-on” on Targetprocess login page.
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:
Still have a question?
We're here to help! Just contact our friendly support team