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.

SAP CPQ Federation

The SAP 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 SAP 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, SAP CPQ acts as a Service Provider (SP). SAP CPQ never works as an identity provider (IdP). In Microsoft terminology Relaying Party – RP stands for Service Provider.

SAP 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.

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

Federation Single Sign-On

SAP CPQ supports the SP and the IdP initiated Single Sign-On. SP FSSO is initiated by the SAP CPQ application. To utilize this, SAP 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 SAP 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 SAP 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.

SAP 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 SAP CPQ Application?

  1. Set up an operational Identity Provider (this will not be maintained by the SAP CPQ team).
  2. Request federation support for your environment from your SAP 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 SAP CPQ application that will be sent to you.
  4. Harmonize with the SAP CPQ team regarding which bindings and other protocol details will be in use.
  5. A new federation URL will be exposed for SAP CPQ SP-initiated FSSO for your environment.

SAP CPQ FSSO URL Naming

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

Per sample:

SAP 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 SAP 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 SAP 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 SAP CPQ over the user import functionality. Users should be imported with the same usernames.

At present, SAP 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 SAP CPQ if they are coming to SAP 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 SAP 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 SAP 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 SAP 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 SAP CPQ sends within email notifications have their Federation counterparts. Depending on the user’s authentication (local SAP 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 SAP 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 SAP 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 SAP CPQ Online HelpAdmin Page HelpFederated Single Sign-On