QuickbaseTeam
Quickbase Staff
Joined 5 years ago
User Profile
User Widgets
Contributions
SAML Public Authentication Certificate for Signed Authn Requests
June 21st, 2024 Update: We have created a Quickbase app to host the Quickbase SAML Zip File. Access the app by clicking the link above to download the file. For Quickbase Realm and Account Administrators As a Quickbase Realm or Account Administrator, you are probably aware of how your users authenticate (login) to the Quickbase platform. Many Quickbase customers use our SAML authentication feature. Security Assertion Markup Language, or SAML, is a standardized way to tell external applications and services, such as Quickbase, that a user is who they say they are. SAML makes single sign-on (SSO) technology possible by providing a way to authenticate a user once and then communicate that authentication to multiple applications. To help you understand what you may be using at your company, some examples of SAML, SSO or IdP (Identity Provider) vendors are Okta, OneLogin, Microsoft, Duo, and there are many others. Some customers using the SAML authentication feature may also choose to use an extra layer of security whereby each authentication request from the Quickbase platform to your company’s SSO directory (or IdP) is signed by Quickbase using a public authentication certificate configured on the Quickbase platform. Quickbase refers to this extra security feature as the “SAML Authn Requests” option. It has that name because there is a feature in the Quickbase SAML configuration settings named “SAML Authn Requests”. Only Quickbase staff can see this option or change it. It is only enabled when a customer informs Quickbase of the customer's intention to configure their IdP to require signing of authentication requests made by the Quickbase platform to the customer's IdP as part of the SAML authentication process. If a customer wants to know if they are using the “Signed Authn Requests” option, or would like the option enabled or disabled, they can open a support case with Quickbase Technical Support. *When the “SAML Authn Requests” feature is enabled by Quickbase, and the customer has configured their IdP to require signing of authentication requests made by the Quickbase platform to the customer's IdP as part of the SAML authentication process, both Quickbase and the customer’s IdP must use the same public authentication certificate in order for Quickbase authentication to work successfully. If they do not match, Quickbase authentication (logins) will fail and the customer will be unable to use Quickbase. Once a year, Quickbase is required to rotate the public authentication certificate. The certificate rotation will occur on a specific date/time within a 15 minute maintenance window. Therefore, the certificate rotation process requires careful coordination between Quickbase and all customers who have chosen to use the “SAML Authn Requests” feature. Typically, about 2 weeks prior to the annual rotation, Quickbase will communicate to Realm and Account Administrators for customers using the “SAML Authn Requests” feature via in-product messaging and possibly also e-mail. We also post a notice on the Quickbase service page. We provide a link to this Community post which specifies in a section below the date and time of the rotation and provides a link to download the new public authentication certificate. *The Realm and Account Administrators need to contact the person or team at their company responsible for administering their IdP/SSO/SAML system, typically their IT department, in order to ensure that the new public authentication certificate from Quickbase is also installed in the customer’s IdP/SSO/SAML system during the 15 minute maintenance window announced by Quickbase. *The public authentication certificate CANNOT be changed in your company’s IdP prior to the announced maintenance window or logins to the Quickbase platform will break. If the certificate is not changed in your company’s IdP during the 15 minute maintenance window announced by Quickbase, logins to the Quickbase platform will be broken until the certificate is updated in the IdP. For Single Sign-On (SSO) or Identity Provider (IdP) Administrators: PLEASE NOTE: The remainder of this Quickbase Community post is highly technical and should be reviewed by the person or team responsible for administering the Single Sign-On (SSO) or identify provider (IdP) system used to control access to the Quickbase platform. Single sign-on (SSO) is an authentication method that enables users to securely authenticate with multiple applications and websites by using just one set of credentials (username and password). An identity provider (IdP) system is a directory of usernames, passwords, groups, roles, etc. that is typically used to manage access to the applications used by a company. Another acronym commonly associated with Single Sign-On is SAML. Security Assertion Markup Language, or SAML, is a standardized way to tell external applications and services that a user is who they say they are. SAML makes single sign-on (SSO) technology possible by providing a way to authenticate a user once and then communicate that authentication to multiple applications. Many customers use Quickbase's SAML authentication feature. A subset of customers may have the “Signed Authn Requests” option selected in their Quickbase SAML configuration. That option is a security enhancement that results in Quickbase signing the authentication requests made to the customer’s identify provider (IdP). Use of this option also requires the customer to configure their IdP to require signing of authentication requests made by the Quickbase platform to the customer's IdP as part of the SAML authentication process. *Customers who choose to use the “Signed Authn Requests” option and enable signing of authentication requests on their IdP must be prepared to manage the annual public authentication certificate update process described below. The option itself offers only marginal security benefit so customers should decide for themselves if that marginal security benefit is worth the effort required to coordinate and execute the update of the certificate and potentially incur several minutes or more of down time for their use of the Quickbase platform while the public authentication certificate on their IdP may not match the certificate used on the Quickbase platform. The “Signed Authn Requests” option is only visible to Quickbase staff and can only be changed by Quickbase staff. It should only be enabled when a customer informs Quickbase of the customer's intention to configure their IdP to require signing of authentication requests made by the Quickbase platform to the customer's IdP as part of the SAML authentication process. If a customer wants to know if they are using the “Signed Authn Requests” option, or would like the option enabled or disabled, they can open a support case with Quickbase Technical Support. In order to validate that the signed authentication requests actually come from Quickbase, we provide the customer with a public authentication certificate. Customers using the “Signed Authn Requests” option must ensure their IdP is configured with the public authentication certificate currently being used by the Quickbase platform to sign authentication requests made by the Quickbase platform to the customer's IdP as part of the SAML authentication process. If the public authentication certificate configured in the customer’s IdP does not match the public authentication certificate being used by Quickbase, the customer will not be able to authenticate successfully to the Quickbase platform. *Quickbase has no ability to know if or how a customer has configured their IdP. We therefore cannot tell a customer if their IdP is requiring Quickbase to sign authentication requests and we cannot tell a customer if the public authentication certificate Quickbase is using matches the certificate the customer has configured in their IdP. Quickbase rotates the public authentication certificate every year and distributes it to applicable customers inside a certificate file via this Quickbase Community post. Quickbase determines the applicable customers based on which have the “Signed Authn Requests” option enabled in their Quickbase SAML configuration. During the period of time starting on the date that we announce our intention to update the certificate, and ending after the date/time we actually update the certificate on the Quickbase platform, we make both the current and new certificates available in this Community post. After we update the certificate on the Quickbase platform, we then remove the now out-of-date certificate from this Community post. Prior to the annual public authentication certificate rotation period, Quickbase will communicate via in-product messaging and possibly also e-mail to Quickbase realm and account administrators at the applicable customers the specific date/time on which we intend to update the certificate on the Quickbase platform. When Quickbase updates the certificate, we do so during a 15 minute maintenance period on the announced date/time. We strive to provide customers with enough notice of this maintenance period for them to notify their responsible staff, typically their IT department or whichever group within the customer’s organization is responsible for administering their identify provider (IdP) system. The customer’s IdP administrator should plan to update the public authentication certificate provided by Quickbase during the 15 minute maintenance period announced by Quickbase. Doing so will minimize the chance of the customer experiencing any interruption of their use of the Quickbase platform. PLEASE NOTE: For any customer using the “Signed Authn Requests” option, i.e., requiring signing of authentication requests made by the Quickbase platform to the customer's IdP, any time the public authentication certificate used by Quickbase does not match the public authentication certificate configured in the customer's IdP, logins to the Quickbase platform will fail. It is therefore essential that the customer update the public authentication certificate in their IdP during the 15 minute maintenance period announced by Quickbase annually. Quickbase Public Authentication Certificate Rotation Maintenance Window Quickbase plans to update the public authentication certificate on Wednesday, November 20, 2024, between 8:00 PM and 8:15 PM Eastern US Time. Current and New Public Authentication Certificates The NEW public authentication certificate is provided below for you to download and install on your identify provider during the 15 minute maintenance period. The zip file contains both the metadata (with certificate contained inside) as well as the certificate on its own. Current Certificate (Expires November 24, 2024): QB_SAML_Exp11-24-2024.zip NEW Certificate: (Expires November 25, 2025): QB_SAML_Exp11-25-2025.zip Additional Information on SAML Public Authentication Certificate Configuration Scenarios and Expected Outcomes This section describes several scenarios that could exist specific to a Quickbase customer using SAML authentication for access to the Quickbase platform. Quickbase SAML configuration option “Signed Authn Requests” is disabled, and Customer does not configure their IdP to require signing of SAML authentication requests. In this case, logins to the Quickbase platform will work normally assuming there are no other SAML configuration issues. There is no use of public certificates in this scenario. Quickbase SAML configuration option “Signed Authn Requests” is disabled, and Customer configures their IdP to require signing of SAML authentication requests, and has the currently applicable public authentication certificate from Quickbase installed in their IdP. In this case, logins to the Quickbase platform will fail because the Customer's IdP is expecting authentication requests from Quickbase to the IdP to be signed and Quickbase is not signing them because the “Signed Authn Requests” option is disabled. Quickbase SAML configuration option “Signed Authn Requests” is enabled, and Customer configures their IdP to require signing of SAML authentication requests, and has the currently applicable public authentication certificate from Quickbase installed in their IdP. In this case, logins to the Quickbase platform will work normally because the Customer's IdP is expecting authentication requests from Quickbase to the IdP to be signed using the currently applicable public authentication certificate and Quickbase is signing them with that same public authentication certificate. Quickbase SAML configuration option “Signed Authn Requests” is enabled, and Customer configures their IdP to require signing of SAML authentication requests, and has a public authentication certificate installed in their IdP that is either expired, or does not match the public authentication certificate currently being used by Quickbase. In this case, logins to the Quickbase platform will fail because the Customer's IdP is expecting authentication requests from Quickbase to the IdP to be signed using the public authentication certificate they have configured in their IdP and Quickbase is signing them with a different public authentication certificate. Quickbase SAML configuration option “Signed Authn Requests” is enabled, and Customer does not configure their IdP to require signing of SAML authentication requests. In this case, logins to the Quickbase platform may or may not work normally depending on the IdP and how it handles a signed request. Quickbase cannot anticipate how different IdPs may handle this scenario. The solution is to open a case with Quickbase Technical Support and request that the “Signed Authn Requests” option be disabled.Quickbase Sync SFTP Connections - Ending Support for SHA-1
Quickbase is focused on continually helping our customers improve their security by using the safest security protocols and aligning with industry best practices for data security and integrity. For that reason, Quickbase Sync (for connected tables) will be updating the SFTP connector to only allow connections to SFTP servers that use SHA-2. See the list of supported algorithms below. To give you time to transition, the current version of the SFTP connector (Version 1) will continue to be available for existing connections until the Quickbase May 2024 release. Beginning with the Quickbase November 2023 release, connection owners can switch existing connections to the new version (Version 2). Quickbase may automatically switch some connections to Version 2 based on the server version and algorithm currently being used by the connection’s SFTP server. New connections created after the November 2023 release will use Version 2. What do you need to do? If you are the owner of an SFTP connection in Quickbase, confirm with the administrator of your SFTP server that it is not using SHA-1. If it is, ask that they upgrade to SHA-2. After the November 2023 release, follow these steps to update your SFTP connection to use Version 2 of the SFTP connector: Select the user dropdown on the Global bar, then choose My Preferences. In the My Connections section, select the SFTP connection you want to update. Change the Client Version from 1 to 2 and re-enter the SFTP password. Click the Save button to save your changes. Go to one of the connected tables that uses the connection and manually refresh the table to confirm that the refresh works. Supported key algorithms: ecdsa-sha2-nistp256-cert-v01@openssh.com ecdsa-sha2-nistp384-cert-v01@openssh.com ecdsa-sha2-nistp521-cert-v01@openssh.com ssh-ed25519-cert-v01@openssh.com rsa-sha2-512-cert-v01@openssh.com rsa-sha2-256-cert-v01@openssh.com ecdsa-sha2-nistp256 ecdsa-sha2-nistp384 ecdsa-sha2-nistp521 ssh-ed25519 sk-ecdsa-sha2-nistp256@openssh.com sk-ssh-ed25519@openssh.com rsa-sha2-512 rsa-sha2-256 ssh-rsa Supported kex algorithms: curve25519-sha256 curve25519-sha256@libssh.org curve448-sha512 ecdh-sha2-nistp521 ecdh-sha2-nistp384 ecdh-sha2-nistp256 diffie-hellman-group-exchange-sha256 diffie-hellman-group18-sha512 diffie-hellman-group17-sha512 diffie-hellman-group16-sha512 diffie-hellman-group15-sha512 diffie-hellman-group14-sha256 ext-info-c2023 Quickbase US Instance Hosting Transition Plan
This bulletin informs Quickbase customers of a plan to transition parts of the US Instance of the Quickbase platform between our existing hosting locations during 2023 and introduce a new hosting location in Q4 of 2023 and early Q1 of 2024. This hosting transition will be accomplished using planned down time similar to the data center switches we typically do 2-3 times per year. No action will be needed by customers aside from being aware of the planned down time as it is announced during 2023 or 2024. Linked here you can find a full explanation of the hosting transition, and a visual depiction of the milestones. The primary objectives of the hosting transition are: Upgrade the Quickbase infrastructure that serves 3+ billion requests per month, while simplifying the process of future upgrades. Simplify the processes Quickbase uses to host and operate the Quickbase platform, while maintaining the same level of functionality, security/compliance, reliability, performance, and scalability. Continue to accelerate the pace of innovation for delivering world-class capabilities to our customers. As we are ready to execute each step of the Hosting Transition, we will send e-mail to realm and account admins for active Quickbase customers, and we will post on the Quickbase service page. If you have any questions, please contact your Quickbase Account Team. To learn more about this project, please see the additional materials below: US Quickbase Hosting Transition Plan US Quickbase Hosting Transition DiagramNew Rate-Limit Exceeded Error Page
If you encounter the below error message, it indicates that we’re experiencing heavy traffic to your Quickbase application from your IP address. Accordingly, we’ve placed a temporary block to avoid performance issues to your application. If you continue to see this message, please reach out to Care for further assistance. Please include the URL from your browser and the date/time you received the error message in your case with Care, as this will help the agent more quickly assist you.Root Cause Analysis for Quick Base Production Incident on 2020-Jun-09
Incident Overview Between 4:33 PM and 5:23 PM Eastern US Time (50 Minutes) on Tuesday, June 9, 2020, the Quick Base platform was unavailable due to an accidental deletion of the public SSL certificate issued on our behalf by our CDN and DDOS prevention service, Cloudflare. An SSL certificate (more accurately called a TLS certificate), is necessary for a website to have HTTPS encryption, thereby making the connection between our customers and the Quick Base platform secure. The accidental deletion of the public SSL certificate used by the Quick Base platform occurred during a configuration change process initiated by Cloudflare for which the Quick Base team was not given advance notice, and Cloudflare could not roll back the changes. Cloudflare did not intend for the configuration changes to be disruptive but, in hindsight and with further review, they acknowledge that they did not account for all the possible consequences that could result from the configuration changes. Cloudflare has acknowledged the mistake and takes full responsibility. They are continuing to investigate the specific details that led to the mistake and we will make those details available once we get them from Cloudflare, which is expected to occur by June 17. Meanwhile, we are continuing to investigate and define the consequences of the Cloudflare configuration changes and assisting impacted customers. We will update this post as more information becomes available. We understand that Quick Base customers rely on us for your important business processes each day and we strive to provide a world-class level of security, availability and performance for the Quick Base platform. Cloudflare is an essential partner in that effort. Although Cloudflare did not live up to our collective expectations with respect to their change management practices in this case, we are confident they will respond to this issue in a manner that will prevent such an issue from occurring again and continue to deliver the excellent security and availability on which their own business has been built. NOTE: This incident did NOT and does NOT result in any security risk for Quick Base customers or their data. During this incident, Quick Base customers were unable to access the platform because we require a secure connection to be established before any data is sent by your browser or API scripts to the platform. Since the secure connection could not be established, no data ever left a customer’s network, i.e., their browser sessions or API scripts. If you believe you are continuing to be negatively impacted by this incident we encourage you to read the remainder of this document for possible solutions and otherwise please submit a support case at https://www.quickbase.com/support. Incident Details We believe in a culture of transparency. To that end, we have included further details for those interested, or for customers that may still be experiencing issues. The changes that occurred as part of the unannounced configuration change process initiated by Cloudflare on Tuesday, June 9, 2020, were as follows (all times are Eastern US Time): The public wildcard SSL certificate, i.e., *.quickbase.com, provisioned on behalf of Quick Base by Cloudflare, was accidentally deleted at 4:33 PM Eastern US Time resulting in the Quick Base platform being unavailable to customers. This is the certificate used to establish a trusted and encrypted connection between our customers and the Quick Base platform each time customers use the platform. The common terms used to describe the establishment of this trusted connection are "handshake" or "SSL handshake". Our monitoring systems detected a problem with the platform immediately at 4:33 PM, we triaged the issue and determined the SSL certificate had been deleted. We called Cloudflare at 4:43 PM and a new wildcard SSL certificate was provisioned by them thereby restoring access to the platform at 5:23 PM Eastern US Time. The SSL certificate chain was changed, including the public wildcard certificate and other certificates in the chain. A certificate chain is an ordered list of certificates, containing an SSL Certificate and Certificate Authority (CA) Certificates, that enable your browser or API script to trust the *.quickbase.com certificate because that certificate, itself, is trusted by other certificate authorities in the chain that your browser or API script already trust. The chain terminates with a Root CA Certificate. The Root CA Certificate is always signed by the CA itself. SNI (Server Name Indication), which is an extension of the TLS (SSL) protocol, was enabled as a requirement for every connection made between our customers and the Quick Base platform. SNI is an industry standard supported by 99.96% of hosts on the Internet (study conducted by Akamai). Only very old software and operating systems do not support it (mostly pre-2015 versions of software). Although the Quick Base platform itself does not require the use of SNI, Cloudflare made it a requirement for establishing the trusted connection, i.e., the SSL handshake. As of 7:15 PM Eastern US Time on Thursday, June 11, Cloudflare has disabled SNI as a requirement. The public IP addresses to which the Quick Base platform host names resolve were changed, i.e., the IP addresses to which <yourcompany>.quickbase.com resolve were changed. Ongoing Incident Issues For 99.9% of Quick Base customers, once Cloudflare provisioned a new SSL certificate for Quick Base, which occurred at 5:23 PM Eastern US Time on June 9, access to the Quick Base platform was restored and those customers were able to use the platform without further issues. However, some customers continued to report issues after the new certificate was provisioned. The following is a list of the issues we have seen and the potential solutions or status of each. Customers using a browser or API script to access Quick Base who do not have Quick Base specific IP address routing rules or restrictions in place on their local network. A browser session or API script that has been open since before the start of the incident may try to get to the Quick Base platform using the public IP addresses used by Quick Base prior to the incident. Potential Solutions, listed first for a browser and then for an API script (in order of most probable solution): If you are using a browser to access Quick Base, try the following steps, in order: Close/open the browser session (that means close ALL currently open browser windows). Clear the browser cache and close/open the browser session (that means close ALL currently open browser windows after clearing the browser cache in one of them). Use a different browser. For example, if you are having trouble accessing Quick Base using the Chrome browser, try using another browser you may have installed on your computer, e.g., Firefox. Reboot your computer. Contact your IT department and ask them to remove <yourcompany>.quickbase.com from the cache of the DNS server used by your computer, or to restart the DNS server used by your computer. If you get to this step, you should repeat the prior steps if this step alone does not resolve your issue. Please note, the reference to <yourcompany>.quickbase.com should be replaced with whatever name you use in the URL field of your browser to access QuickBase, e.g., https://companyname.quickbase.com. If you are running an API script to access Quick Base, try the following steps, in order: Restart the API script or the service/program that runs the API script. Reboot the computer on which the API script is running. Contact your IT department and ask them to remove <yourcompany>.quickbase.com from the cache of the DNS server used by the computer on which the API script is running, or to restart the DNS server used by the computer on which the API script is running. Please note, the reference to <yourcompany>.quickbase.com should be replaced with whatever name you use in the API requests, e.g., https://companyname.quickbase.com. Customers using a browser or API script to access Quick Base who do have Quick Base specific IP address rules or restrictions in place on their local network. The practice of using a website's public IP addresses as part of local network rules or restrictions is known as “IP allowlisting”. Some examples of IP allowlisting are 1) only allowing use of the Internet for designated sites, such as Quick Base, by specifying in the customer’s local network rules the public IP addresses to which the Quick Base platform host names resolve, and 2) requiring all traffic destined for Quick Base (as defined by our public IP addresses) to use a specific VPN connection on the customer’s local network. The VPN use case is often paired with the use of Quick Base's “IP Address Filtering” feature which allows access to a Quick Base application, or an entire realm, to be limited to only certain client IP addresses. By forcing all traffic destined for Quick Base to come from the IP addresses used by the customer's VPN, the “IP Address Filtering” list only needs to include the IP address or address range used by the customer's VPN. Potential Solutions (in order of most probable solution): Quick Base does not support, and highly discourages, the use of IP address allowlisting as part of a customer’s local network rules or restrictions. The public IP addresses to which the Quick Base platform resolves can and do change without notice. Relying on IP address allowlisting on your local network can result in disruption to your access to the Quick Base platform if Quick Base’s public IP addresses change. If you are unable to discontinue use of IP allowlisting on your local network at this time, you may, at your own risk, use the following public IP addresses in your IP allowlist: 104.18.100.30 and 104.18.101.30. Any DNS lookup on a <realm>.quickbase.com host name will resolve to one of these two IP addresses which, as noted, are subject to change without notice. For example, if you do a DNS lookup on <companyname>.quickbase.com where <companyname> is the name of your realm in Quick Base, it will resolve to one of the two aforementioned IP addresses. Customers accessing Quick Base using a browser or API script that uses a locally installed copy of the public Quick Base SSL certificate, or SSL certificate chain. For example, customers may configure browsers, computer operating systems, or API scripts to refer to locally stored copies of public SSL certificates or SSL certificate chains instead of referencing the SSL certificates or SSL certificate chains directly on a destination website such as the Quick Base platform. Some common reasons for this practice are 1) the customer’s compute environment does not trust one or more of the SSL certificates in the SSL certificate chain, or 2) the customer wants to compare the locally installed SSL certificate or SSL certificate chain with the version from the website such as the Quick Base platform. Potential Solutions (in order of most probable solution): Quick Base does not support, and highly discourages, the use of locally installed SSL certificates or SSL certificate chains. Quick Base and Cloudflare use widely trusted SSL certificates, SSL certificate chains, and Certificate Authorities. SSL certificates and SSL certificate chains used by the Quick Base platform can and do change without notice. Relying on locally installed SSL certificates or SSL certificate chains can result in disruption to your access to the Quick Base platform if Quick Base’s public SSL certificate or SSL certificate chain change. If you are unable to discontinue use of locally installed SSL certificates or SSL certificate chains at this time, you may, at your own risk, download and install the public Quick Base SSL certificate and/or SSL certificate chain. Customers accessing Quick Base using a browser, computer operating system, or API script that does not support the SNI (Server Name Indication) TLS protocol extension either because the browser, computer operating system, or software used to run the API script is too old (typically a version from prior to 2015), or the software is specifically configured to NOT support SNI. As noted earlier in this document, although the Quick Base platform does not require the use of SNI, Cloudflare made it a requirement for establishing the trusted connection, i.e., the SSL handshake. Quick Base worked with Cloudflare to determine if it is possible to disable the required use of SNI and as of 7:15 PM Eastern US Time on Thursday, June 11, Cloudflare has disabled SNI as a requirement. NOTE: It is our intention to re-enable the required use of SNI at a date no later than September 30, 2020. Therefore, customers who experienced ongoing issues due to lack of support for SNI should plan to upgrade their browsers, computer operating systems, or API scripts to a version that supports SNI and to configure support for SNI no later than September 30, 2020. Customers accessing Quick Base using a browser, computer operating system, or API script that does not support TLS 1.2 or above. Although Cloudflare, nor Quick Base, changed our support of TLS recently, some customers have asked what version of TLS we support as part of support cases opened about this incident. Quick Base only supports encrypted requests using TLS v1.2 or v1.3. You can find more information about our TLS support in this Quick Base Community post.
