Federated Single Sign-On

Single sign-on (SSO) is a session/user authentication process that permits users to enter a single name and password in order to access multiple applications.
While SSO uses a single login (Username/Password) to access all applications within the same organization, Federated SSO (FSSO) goes a step further and extends SSO across enterprises. In other words, FSSO single access to multiple systems across different organizations, benefitting users and organizations alike.

What are the benefits of a Single Sign-On?

  • User experience With SSO users authenticate only once at a single point and enjoy a seamless experience across multiple domains. There is no need to remember separate credentials for each cross-domain because users retain only one pair of credentials. This means they can securely move between services with no interruptions, and without having to enter their credentials upon entering each new domain.
  • Fewer time costs When working with cross-domain applications, it can take up to 30 seconds to sign on to a web application. And that's not counting the cases when users mistype their username or password and have to re-enter them. SSO solves this problem by entering credentials only once on the IdP side. By saving time, users also boost their productivity.
  • Security The users' credentials are provided directly on the central SSO server, not on the actual service the user is trying to access. As a result, the credentials cannot be cached by the service. The central authentication point, the SSO service, reduces the possibility of phishing.
  • Password management It reduces administrative overhead in resetting forgotten passwords over multiple platforms and applications.

CPQ Federation

The CPQ Federated Authentication uses the Security Assertion Markup Language (SAML) 2.0 protocol and enables you to send authentication and authorization data between cross domain applications. In turn, this enables you to sign on a remote Identity Provider and to access the CPQ application. The Federated Authentication using SAML can be enabled on request for your organization.

Information about SAML 2.0 protocol details can be found here.

For remote identity providers, CPQ acts as a Service Provider (SP). CPQ never works as an identity provider (IdP). In Microsoft terminology Relaying Party – RP stands for Service Provider.

CPQ supports two major SAML 2.0 profiles:

  • Federation Single Sign On (FSSO), which signs on users on all systems in Federation Trust.
  • Federation Single Sign Out (FSLO), which signs out users from all systems in Federation Trust.

More details about SAML 2.0 profiles can be found here.

CPQ does not support WS-Federation (Ws-Fed) federation protocol.

Federation Single Sign-On

CPQ supports the SP and the IdP initiated Single Sign-On. SP FSSO is initiated by the CPQ application. To utilize this, CPQ, as a SaaS application, will expose the new URL address specific to your tenant environment. On the other hand, IdP-initiated FSSO begins from IdP and, following authentication, sends the user to the CPQ default page.

As for the FSSO profile (authentication flow) we prefer Redirect binding:-urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect

We do not support Artifact binding at this time: -urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Artifact

Binding details are specified in the Service Provider metadata that will be sent to you for the specific CPQ environment.

Federation Single Sign-Out

For the FSLO profile (Sign-Out Flow) we prefer Redirect binding, (urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect)

You may find information about SAML 2.0 bindings here.

CPQ supports local and federated single sign-out scenarios. For the post sign-out we support default and custom processing. Custom processing covers response actions received after sign-out (e.g. redirect to specific URL or call some publicly visible API).

How to Establish Federation With CPQ Application?

  1. Set up an operational Identity Provider (this will not be maintained by the CPQ team).
  2. Request federation support for your environment from your CPQ contact person.
  3. Exchange SAML metadata documents – send us the metadata from your IdP and import the SP metadata on your side from the CPQ application that will be sent to you.
  4. Harmonize with the CPQ team regarding which bindings and other protocol details will be in use.
  5. A new federation URL will be exposed for CPQ SP-initiated FSSO for your environment.


CPQ has for each identity provider specific SP initiated URL address. It is created from CPQ domain address + fed keyword + IdP specific url segment. It is created from the CPQ domain address + fed keyword + IdP specific url segment.

Per sample:

CPQ root address: https://www.rs.webcomcpq.com
Identity provider url segment: test
Result URL address: https://www.rs.webcomcpq.com/fed/test/

The identity provider URL segment is not the same as the tenant/domain name. It can be the same, but in most cases it is a separate value. Do not rely on the identity provide URL segment to be the same value as the name of the tenant.
Note that the root domain URL will take you to the local login screen.

User Mappings

When using the federation authentication, local CPQ users should also be created. Why? Because each federated user will be mapped to the local user during the authentication process. Local users are mandatory as they are integrated with local application and the db schema.

As a result of the central authentication process, the central user identifier (UID/UPN) will be delivered from the Identity Provider over SAML protocol. The Federated user will be mapped to the local user based on the username. This is why the same username should exist in the CPQ system.

But when the central user should be mapped to a local user with a different username, the FederationId user field should be used. The Federation module will first try to map the local user over the FederationId, than over the local username.

When running as a new Federation tenant, the best practice is to import all users from your remote LDAP/Active Directory into CPQ over the user import functionality. Users should be imported with the same usernames.

At present, CPQ does not support auto-provisioning mechanisms such as SCIM and SPML among others. Nor does it support SAML JIT provisioning.

Regardless if we use Federation or not, the local user’s passwords are always required when adding/importing users. Even though passwords are required, they will not be used; that is, users will not be required to type them anywhere in CPQ if they are coming to CPQ from the Federated landing page. The recommendation is to put a random secret password into every user’s field and not share this password with other users.

New Quote Web Method Under the Federation

NewQuoteForFederation web method
The New quote web method (http://help.webcomcpq.com/doku.php?id=appendixd:newquotewebmethod:newquotewebmethod), has a counterpart when working under the Federation environment. The NewQuoteForFederation has the same parameters as NewQuote webmethod, with the additional one - identity provider name (idpName). The identity provider name is a unique name of the identity provider in SAML terminology, and to which CPQ is connected.
The method’s result link contains a Federation URL segment. This is the sample Federation URL pf the quote that is created: https://www.webcomcpq.com/fed/test/Login.aspx?quote=CECDCCD2CDC8C8CB

NewQuoteForFederationRouting web method
Beside NewQuoteForFederation web method that is described, there is one more method that is used when federation is enabled. It is NewQuoteForFederationRouting. This method is used to create a Quote in case when federation is set up for two or more client's tenants at the same CPQ instance. Route is defined for each tenant and must be provided as a parameter idpRoutingName for the NewQuoteForFederationRouting web method.
The method’s result link contains a Federation URL segment. This is the sample Federation URL pf the quote that is created: https://www.webcomcpq.com/fed/test2/Login.aspx?quote=CECDCCD2CDC8C8CB
You should contact Callidus CPQ support in order to get the appropriate values for parameters idpName and idpRoutingName.

Notification URL’s Under Federation

The PDA approval link and the quote link that CPQ sends within email notifications have their Federation counterparts. Depending on the user’s authentication (local CPQ or remote Identity Provider), the system dynamically determines whether the tags will return a regular or federated (Single Sign-on) links.
If the user was signed on directly to CPQ and generates a notification which contains these tags, the system will send a non-federated URL to an approver. That approver then has to access CPQ directly. And vice versa, federated links will be sent to the approver for the tags generated by the user signed on over Federation. Than approver will need to sign on over the Federation.

Quote link notification tag: <*QUOTELINK*>

PDA approval notification tag: <*PDAAPPROVAL*>

You are here: CallidusCloud CPQ Online HelpAdmin Page HelpFederated Single Sign-On