Single Sign-On in Targetprocess
- Integrations and API
- Import Git / TFVC Version Control Commits from VSTS to Targetprocess
- How to update test run results with REST API
- Bug details synchronization between JIRA and Targetprocess
- Documentation management
- Embedding content from external tools
- Integration between Targetprocess and Slack
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 favourite 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?
- Facilitate easy and secure access for users to their Targetprocess accounts
- Help IT and security departments authenticate users and control application access centrally
- Reduce password maintenance and security overheads
- 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:
Single Sign-On in Targetprocess recognizes users by Email field obtained from identity providers.
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 it’s 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 provided fields:
It’s and identity provider URL endpoint which 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.
With Just-in-Time provisioning, you can use a SAML assertion with an email provided by the identity provider to create Targetprocess users on the fly the first time they try to login. 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 with “John Doe” name with no Projects or Teams assignments. Import of actual user name is not supported. Immediately after the first login the user gets redirected to their profile settings to set First and Last name and password for native Targetprocess authentication if needed. Also, the Targetprocess administrator has to assign such new Users to Projects and Team in Targetprocess to access account data.
If an account with same email exists but was deleted or deactivated, the system will restore and re-activate this user.
Disable login form
This option disables native Targetprocess login form completely and users are automatically redirected to SSO login.
Users listed in this list may access native Targetprocess login form with special “?login=form” added to Targetprocess URL, e.g. https://your_account.tpondemand.com/login.aspx?login=form
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 login to 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 Exceptions list to keep using it
Targetprocess mobile applications usage with SSO
Currently mobile Targetprocess apps for iOS and Android support SAML SSO. There's only one limitation - ADFS SSO with Windows authentication credentials request is not supported, we only support Forms-based authentication.
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 s “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 Provide application log to find additional details.
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 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 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 logout from Targetprocess application (reset authentication cookie) you can use “Logout” in the Targetprocess user menu . In order to logout 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 a SP, that contains the metadata required to sign on or create a user on the SP.
Still have a question?
We're here to help! Just contact our friendly support team