Single Sign-On in Targetprocess

Targetprocess has support for Single Sign-On (SSO). You can now eliminate passwords from the login process and access your applications faster and safer using integration with your favorite identity provider.

Available in Targetprocess v3.6.2+

Single Sign-On in Targetprocess is based on Security Assertion Markup Language 2.0 (SAML 2.0). The purpose of SAML is to enable Single Sign-On for web applications across various domains. SAML is developed by the Security Services Technical Committee of "Organization for the Advancement of Structured Information Standards" (OASIS). Your identity provider must support SAML 2.0 standard.

How does SSO for Targetprocess help you?

1. Facilitate easy and secure access for users to their Targetprocess accounts
2. Help IT and security departments authenticate users and control application access centrally
3. Reduce password maintenance and security overheads
4. Enforce additional password security measures such as password complexity requirements, password expiration, and two-factor authentication (number of features available defined by your identity provider)

User authentication flow using SAML 2.0 SSO:

How can you enable SAML Authentication in Targetprocess

In order to enable SAML SSO for Targetprocess account, the user must have administrative permission. This guide provides you with general information about Targetprocess SAML SSO and its settings. Detailed step-by-step guides for specific identity providers are available in corresponding articles.

• How to setup Single Sign-On with Okta
• How to setup Single Sign-On with OneLogin
• How to setup Single Sign-On with ADFS
• How to setup Single Sign-On with Google G Suite
• How to setup Single Sign-On with Azure AD (external link)
• How to setup Single Sign-On with other providers

To enable SAML SSO you have to open Settings → Authentication and Security → Single Sign-On

To start using SAML SSO please select the “Enable Single Sign-On” checkbox and fill all the fields with your identity provider data. Here’s additional information about the provided fields:

Sign-On URL

It’s an identity provider URL endpoint that processes an authentication request from a user browser and returns an authentication response to verify the user. This URL is typically application-specific so you need to make sure that you’re using the correct URL provided by your identity provider.

Enable JIT Provisioning (Just-in-Time Provisioning)

With Just-in-Time provisioning, you can use a SAML assertion with an email provided by the identity provider to create users on the fly the first time they try to log in. This eliminates the need to create user accounts in advance. For example, if you recently added an employee to your organization, you don't need to manually create the user in Targetprocess, they only have to be added to your identity provider users list (e.g. AD in case of ADFS 2.0 identity provider). When they log in with single sign-on, their account is automatically created for them.

JIT Provisioning creates a generic user named “John Doe” with the default role of “Developer”, with no Projects or Team assignments. Since 3.13.20, the import of first and last names and default role is supported. Just specify the user property mapping to the corresponding parameter name. After the first login, the user gets redirected to their profile settings to set first and last names, and a password for native Targetprocess authentication if needed. Also, the Targetprocess administrator has to assign such new Users to Projects and Teams in Targetprocess to access account data.

The ‘Enable Just-In-Time provisioning for …’ options can be configured separately for Targetprocess and Service Desk.

When ‘Enable Just-In-Time provisioning for Service Desk’ is enabled, any new and not yet known user that is logging in via SSO to Service Desk, is created as ‘requester’ in Targetprocess.

When ‘Enable Just-In-Time provisioning for Targetprocess’ is enabled, any new and not yet known user that is logging in via SSO to Targetprocess, is created as a full 'licensed user' in Targetprocess.

Using these separate JIT settings, it’s possible to configure it such that new users are prevented from being (Just-In-Time) automatically provisioned as a licensed user into Targetprocess but do get provisioned as 'requester' into Service Desk or vice versa.

Login claims

The configuration of required login claims allows one to control more specifically whether a particular user or requester is allowed to login via SSO to Targetprocess or Service Desk. If a claim name is configured, then its presence in the user data is checked during each login attempt. The value of the claim itself doesn’t matter. If the claim is absent from the user data, the user is not allowed to login via SSO. In order to enrich user data provided by identity providers with required claims, administrators must configure additional user fields.

If an account with the same email exists but was deleted or deactivated, the system will restore and re-activate this user whenever Enable JIT Provisioning option is enabled or not.

Disable login form

This option disables the native Targetprocess login form completely and users are automatically redirected to SSO login.

Exceptions list

Users listed in this list may access the native Targetprocess login form with the special URL specified in Settings ➜ Authentication and Security (this URL is unique per account)

It’s always a good idea to add at least one Targetprocess administrator to this list to ensure that someone will be able to access Targetprocess settings if the identity provider goes offline or incorrect SSO settings were saved and users cannot log into Targetprocess using SSO due to a configuration error.

REST API usage

The enabled SSO feature may affect your REST API integrations, so if you’re using Targetprocess REST API to access data from third-party applications/services - please read this section carefully.
There are three main ways to use REST API with SSO-enabled Targetprocess:

• Use token authentication for your REST requests, which is the most recommended and safest way. You won’t have to worry about which authentication type is enabled for Targetprocess
• Basic authentication with mixed native/SSO authentication enabled you can use basic authentication for any user
• Basic authentication with SSO-only authentication enabled you’ll have to add your REST user to the Exceptions list to keep using it

Troubleshooting

There are the following common problems with SSO:

• Error 404 Not found - this means there is an incorrect URL either in the Targetprocess SSO settings or in Identity Provider settings. Please double-check your settings in Identity Provider and Targetprocess to make sure URLs are valid
• You’re receiving “Sorry, you can't access Targetprocess application” error. To resolve this problem make sure that your user is assigned to Targetprocess application on step 3 and you’re using the correct account to login to Targetprocess.
• Wrong settings such as incorrect certificate information - you’ll get a corresponding error and will have to open your SSO settings and fix the problem.

Other problems are less common. For those, we'd recommend you check the Targetprocess System Log and your Identity Provider application log to find additional details.

FAQ

Q: I don't see SSO available in Settings for my account, where is it?
A: SSO was enabled by default starting from August 2016, so if your account was created before August 2016 - please contact Targetprocess Support to enable SAML SSO for your account.

Q: Does Targetprocess SSO support Google+ SSO?
A: No, Google+ is using OAuth protocol while Targetprocess supports SAML 2.0 only. You may consider using an intermediate Identity Provider to “translate” Google+ identity to SAML 2.0 ( e.g. PingIdentity) or use Google Apps SAML SSO.
The same applies to other protocols such as Facebook Connect.

Q: Can I use SSO with Share Board service?
A: Yes, and you don’t need any additional setup for that.

Q: Can I use SAML 2.0 SSO with Windows authentication for my On-Site Targetprocess installation?
A: No, in order to use SAML 2.0 SSO in Windows domain environment you must switch to AD FS 2.0 and disable Windows authentication for your Targetprocess website in IIS and leave Forms and Anonymous only.

Q: Do I need to set up special network rules for Targetprocess server or identity provider server
A: Typically, no. All requests are made via an end-user browser so you only have to make sure that end users can access both the identity provider server and Targetprocess server.

Q: How do I sign out from Targetprocess with SSO?
A: To log out from Targetprocess application (reset authentication cookie) you can use “Logout” in the Targetprocess user menu. In order to log out from Identity provider - you need to access your Identity provider main page and use its sign out feature.

Q: Does Targetprocess support both IDP-initiated and SP-initiated SSO flows?
A: Yes, both types are supported

Q: I am getting “[User.Is Active]: There are no more licenses available. If you need more users, either make some current users inactive or purchase more licenses at Settings -> License..” error when trying to login to Targetprocess.
A: Your Targetprocess account has JIT provisioning enabled and the system is trying to create an account for you, but there are no remaining licenses available. Please contact your Targetprocess administrator to purchase a Targetprocess license for you.

SAML SSO Terminology

SAML SSO has two high-level concepts used to identify the systems in a SAML SSO scenario:

• Service Provider (SP): The application the user needs to access in this case, the Targetprocess service.
• Identity Provider (IdP): The sign-on system that will authenticate the user via username and password, or another verification method.

All SAML SSO scenarios share common terminology to describe requests and responses between the SP and IdP:

• Authentication Request (AuthnRequest): A request from the SP to the IdP, made on behalf of the user after they initiate sign-on. MindTouch initiates sign-on when a user clicks the sign-on link or attempts to visit a protected resource such as a page or file attachment.
• Assertion: An XML document, either part of an IdP's response to an authentication request or an IdP's unsolicited request to sign a user into an SP, that contains the metadata required to sign on or create a user on the SP.