Integration Type - Single Sign-on


This SSO service is designed for a user to be set up on a customer's existing Quik! account, with automatic user registration if the user does not exist. 

What is SSO (Single Sign-on) Authentication?

Single-Sign-On (SSO) enables a user from one application to automatically log in to another application without any manual intervention, and often without even knowing their credentials. Because users are managed and authenticated by customer systems (e.g. Active Directory) it's easier on users to use SSO with Quik! than to force users to know, remember and use their own private credentials.

Quik! SSO uses SAML (2.0). The IdP is the Identity Provider (e.g. SalesForce) who has already authenticated the user's identity and wants Quik! to accept that user's authentication in lieu of doing our own authentication. The mechanism that enables Quik! to trust the IdP is that customers have set up their encryption certificate's public key with Quik! and Quik! can use that key to verify their encrypted requests with that key (the assumption is that the IdP is the only one with the private key that is used to encrypt the request). Steps on how to get started with SSO into the Quik! App can be found at the bottom of this page.

Quik! App SSO Process 

The overall flow follows these steps:

  1. User originates outside of Quik! in a customer or partner 3rd party system/platform/application
  2. User clicks a link/button/event to go to Quik!
  3. 3rd party system initiates an SSO Request and gets back a redirect to Quik!
    1. The Quik! App opens in a new tab for the user
  4. Now that the user is logged into Quik!, they can begin generating forms
    1. The landing page may be variable depending on parameters passed in the SSO request
  5. User will need to have forms selected or to find the forms they want to use
    1. If one or more FormIDs are passed in the SSO then the shopping cart will prefill with those forms
    2. The form search results will display all Form IDs that were passed in SSO
    3. If FormGroupIDs were passed in SSO then the form bundle view is displayed with those Form GroupIDs pre-selected
  6. The user will assign client records to the available roles on the selected forms
    1. The CRM choice may be disabled by request in the SSO so the user cannot select any other CRMs
    2. The client search may be hidden or disabled by request in the SSO so the user cannot add other records
    3. Any Client IDs that were passed in the SSO will display as a list of clients in the client search results
    4. If the Owner 1 record is pre-assigned in the SSO then a client will be pre-assign to that role on the Choose Clients screen
  7. User moves to the Launch page
    1. The rep drop-down list may be locked by request in the SSO
    2. The e-sign drop-down may be locked by request in the SSO
  8. User launches the forms
  9. The Quik! Form Viewer can be configured to enable buttons for Submit, Save, E-Sign or Email
  10. The customer may implement the e-sign meta data web service
  11. The customer's system may process the form data that was submitted and/or integrate with the e-sign vendor


SAML is a protocol and methodology for authenticating users. It was built in .NET as a standalone endpoint and code-base, leveraging ComponentSpace's tools for reading and interpreting SAML XML files. The Quik! SAML project validates and accepts an incoming SAML request from an Identity Provider (IdP). The request is used to authenticate a user, onboard new users, pass data to Quik!, pass data to the Quik! App to control the user experience, and pass data to forms to become part of the form payload that becomes part of the transaction (i.e. hidden data, meta data, etc.).

SAML Project Details


SAML Metadata describes the Quik SAML Service provider metadata

The following production endpoint is to be used for all production SAML requests:

The following UAT pre-production endpoint can be used for testing prior to implementing in a production environment:


The table below lists all possible attributes that can be included in a Quik! SAML request (SAML Assertation XML). Yellow rows represent future attributes that do not yet exist, but are in the Quik! development roadmap.

CategoryNameDescriptionData TypeRequired?
Application DataApplicationIDThe Application ID at Quik!
Application DataAudienceRestrictionValue that specifies who the assertion is for
ALL CUSTOMERS MUST USE VALUE "ServiceProvider" FOR AudienceRestriction
Quik! Account DataCustomerIDQuik! CustomerID assigned to the customer's accountstringYES
Quik! Account DataCustomerUserID Customer's unique UserID from their internal system of recordstringYES
Application ControlTimeoutRedirectURLA URL to send the user to when their logged in session expires or is logged outstringYES
Quik! Account DataUserFirstName User's first namestringYES
Quik! Account DataUserLastName User's last namestringYES
Quik! Account DataUserEmail User's email addressstringYES
Quik! Account DataUsername User's username - if not provided, Quik! will generate a Username for the userstringNO
Quik! Account DataPassword If provided, user's password will be hashed and stored stringNO
Quik! Account DataCustomerUserType Type of user being logged in (e.g Advisor, HomeOffice, etc.)stringNO
Application DataBrokerDealerID The Broker/Dealer's internal ID used with API calls or e-signstringNO
Application DataCustomerClientId The ClientID to assign to Owner1 rolestringNO
Application DataCustomerAccountId The account ID to assign to Account 1 rolestringNO
Application DataFormIDList List of FormIDs to add to the shopping cartcsvNO
Application DataClientIDList List of Client IDs to lookup from the connected CRMcsvNO
Application DataRepIDListList of Client IDs to lookup sales rep records from the connected CRMcsvNO
Application DataRep1RecordID The record ID to assign to Rep 1 rolestringNO
Application DataRepNumberList List of rep numbers to show in the launch screen of the Quik! AppcsvNO
Application Data


List of transaction data objects like a tradeblotter, orders, etc. Must contain a root object called “transactions” which will store an array of objects with the following attributes:

  1. id: the Transaction ID (string)

  2. typeId: the Transaction Type (int): TradeBlotter=1


  "transactions": [
      "id": "a1H0S0000012ZeKUAU",
      "typeId": 1

json stringNO
Application Data{Quik! Field Name} and {Value}Any Quik! full field name and value to prefill onto the formstringNO
E-Sign Meta DataClientCode The user's client IDstringNO
E-Sign Meta DataAccountCode The customer's account IDstringNO
E-Sign Meta DataRepCode The customer's sales rep IDstringNO
E-Sign Meta DataFirmCode The customer's firm (broker/dealer ID)stringNO
E-Sign Meta DataClientTransNumber The customer's transaction number (numeric integer values only)numberNO
E-Sign Meta DataClientTransNumber2 The customer's transaction number (numeric integer values only) - number 2numberNO
E-Sign Meta DataClientTransNumber3 The customer's transaction number (numeric integer values only) - number 3numberNO
E-Sign Meta DataClientTransNumber4 The customer's transaction number (numeric integer values only) - number 4numberNO
E-Sign Meta DataClientTransCode The customer's transaction codestringNO
E-Sign Meta DataClientTransCodeType The description if any of the ClientTransCode so customer knows what the data representsstringNO
E-Sign Meta DataClientTransCode2 The customer's transaction code - number 2stringNO
E-Sign Meta DataClientTransCode2Type The description if any of the ClientTransCode2 so the customer knows what the data representsstringNO
E-Sign Meta DataClientTransCode3 The customer's transaction code - number 3stringNO
E-Sign Meta DataClientTransCode3Type The description if any of the ClientTransCode3 so the customer knows what the data representsstringNO
E-Sign Meta DataClientTransCode4 The customer's transaction code - number 4stringNO
E-Sign Meta DataClientTransCode4Type The description if any of the ClientTransCode4 so the customer knows what the data representsstringNO
E-Sign Meta DataClientTransMetaData Any extra text the customer wants to pass through the meta data service (up to 8000 characters)stringNO
Application ControlEnableESignTurns on or off the e-sign feature for the logged in session of the Quik! AppbooleanNO
Application ControlEnableClientSearchFlag to hide/disable the client search page in the Quik! AppbooleanNO
QFE PropertiesLockPrefilledFields If TRUE, sets the prefilled fields as read-only on the formbooleanNO
QFE PropertiesESignCallbackURL Sets the value of the e-sign Callback URLstringNO
QFE PropertiesSubmitFormOn If TRUE, shows the Submit button in the Quik! Form ViewerbooleanNO
QFE PropertiesSubmitURL Sets the value of the Submit button URL (location where submitted form data will be sent)stringNO
Application ControlAfterLoginDisplayPageThe first view to display after SSO login (e.g. Home, Forms, Clients, Launch, FormViewer)stringNO
Application ControlDatabaseConnectionID Quik! QDBC Connection ID to use when requesting client records, if none then whatever connection exists on the account is usedstringNO
Application ControlLockAssignedRoles Flag to allow user to change pre-assigned rolesbooleanNO
Application ControlLockRepChoiceFlag to disable/enable the rep drop-down in the Launch pagebooleanNO
Application ControlESignConnectionNameDetermines which e-sign connection user can access by passing the ESign connection namestringNO
Application ControlLockESignChoiceFlag to disable/enable e-sign drop-down in the Launch pagebooleanNO
QFE PropertiesLockAllFields If TRUE, sets all fields as read-only on the formbooleanNO
Application DataFormGroupIDList List of FormGroupIDs to get the related forms to add to the shopping cartcsvNO

Getting Started

Follow the steps below to set up SSO to the Quik! App:

  1. Before you begin, make sure your organization has an active Quik! App account
  2. Contact the Quik! team ( or your Quik! sales contact and provide the following information:
    1. Your Quik! Customer ID (ask Quik! if you do not know your customer ID)
    2. Your public X.509 Cerificate. This maps to our CertificateBase64 attribute.
    3. Your EntityID aka Audience URI value which must be a unique identifier. This maps to our Name attribute.
  3. The Quik! team will enable your account for SSO (this can be done same-day)
  4. You must build infrastructure and UI elements in your environment that support some sort of "Send to Quik!" button for users to enter the Quik! App with a SAML request. See the SAML Project Details above for more information on which data points to send to Quik! in the SSO event. 
  5. Quik! recommends that you test your SSO implementation with the pre-production SAML endpoint referenced above.
  6. Once testing is complete, you can use the production SAML endpoint referenced above and begin the SSO process for users in your production environment.