Single Sign-On (SSO)

Single Sign-On (SSO) is only available in the Enterprise plan. More information can be found at our pricing page.

Overview

SSO (Single Sign-On) allows you to login to different apps and websites with a single set of credentials. This saves you time to enter your password every time logging in to Quire, which prevents password frustration caused by trying to remember your password. SSO also increases security since it helps reduce the number of user logins to once each day and with one set of credentials and therefore prevent attacks opportunities from hackers.

When your company uses an IdP (identity provider) such as Okta or OneLogin, you can connect your Quire with the IdP for single sign-on. Once the single sign-on is set up for your Quire organization, the organization members will no longer need a password to log into their Quire accounts.

Configure your IdP (identity provider)

The first step is to set up a connection for Quire with your identity provider first. We work with some of the main providers: Okta or OneLogin, but you can also choose to use your own provider that supports SAML 2.0.

If you choose to connect Quire with other IdPs, you will need to create an application and enter the below information to configure SAML.

After the app is created, copy the Identity Provider URL, Entity ID and the Base64 X.509 certificate to use in the next step.

Lastly, remember to add and assign the members in the IdP to the newly created Quire application.

Configure Quire

The second step for setting up SSO in Quire is to enable it for your organization. Click on the dropdown menu icon next to your organization name then select Options.

Navigate to the Security tab and enable the SAML authentication.

You can set the SSO to be required for all members of the organization or set it as Optional, which will allow the members to sign in with passwords for their Quire accounts or identity provider.

Note: If you are the admin of the organization, you will always need to sign in Quire with your password.

Fill in the Identity Provider URL and Entity ID into the corresponding fields and paste the Base64 X.509 certificate copied from your identity provider into the corresponding field.

Test the SSO before saving it. If there is no problem, then you can click Save.

Once the SSO is set up properly for the organization, the organization members will no longer need a password to log into their Quire accounts.

Integration with Azure AD B2C

To begin, set up an Azure portal and log in with your admin account.

Next, follow the guidelines on this page to add custom policies and the steps outlined here to register a SAML application in Azure AD B2C.

It is important to change the NameID format from objectId to userPrincipalName or email as required by Quire.

If you plan to change the format to userPrincipalName, make sure that you modify the TrustFrameworkBase.xml and SignUpOrSigninSAML.xml files accordingly. Below are examples for these configurations:

TrustFrameworkBase.xml example:

<!-- The following technical profile is used to read data after user authenticates. -->
<TechnicalProfile Id="AAD-UserReadUsingObjectId">
  <Metadata>
    <Item Key="Operation">Read</Item>
    <Item Key="RaiseErrorIfClaimsPrincipalDoesNotExist">true</Item>
  </Metadata>
  <IncludeInSso>false</IncludeInSso>
  <InputClaims>
    <InputClaim ClaimTypeReferenceId="objectId" Required="true" />
  </InputClaims>
  <OutputClaims>

    <!-- Optional claims -->
    <OutputClaim ClaimTypeReferenceId="signInNames.emailAddress" />
    <OutputClaim ClaimTypeReferenceId="displayName" />
    <OutputClaim ClaimTypeReferenceId="otherMails" />
    <OutputClaim ClaimTypeReferenceId="givenName" />
    <OutputClaim ClaimTypeReferenceId="surname" />
    <OutputClaim ClaimTypeReferenceId="userPrincipalName" /> <!-- add -->
  </OutputClaims>
  <IncludeTechnicalProfile ReferenceId="AAD-Common" />
</TechnicalProfile>

SignUpOrSigninSAML.xml example:

<RelyingParty>
  <DefaultUserJourney ReferenceId="SignUpOrSignIn" />
  <TechnicalProfile Id="PolicyProfile">
    <DisplayName>PolicyProfile</DisplayName>
    <Protocol Name="SAML2"/>
    <OutputClaims>
      <OutputClaim ClaimTypeReferenceId="displayName" />
      <OutputClaim ClaimTypeReferenceId="givenName" />
      <OutputClaim ClaimTypeReferenceId="surname" />
      <OutputClaim ClaimTypeReferenceId="email" DefaultValue="" />
      <OutputClaim ClaimTypeReferenceId="identityProvider" DefaultValue="" />
      <OutputClaim ClaimTypeReferenceId="objectId" PartnerClaimType="objectId"/>
      <OutputClaim ClaimTypeReferenceId="userPrincipalName" PartnerClaimType="userPrincipalName"/> <!-- add -->
    </OutputClaims>
    <SubjectNamingInfo ClaimType="userPrincipalName" ExcludeAsClaim="true"/> <!-- modify -->
  </TechnicalProfile>
</RelyingParty>

If you plan to change the format to email, you can refer to this resource for additional guidance.

Upon completion, you will receive the following details required by Quire to proceed with the setup: Metadata, Identity Provider URL, Entity ID, and Base64 X.509 certificate.

Below are examples of what this information may look like:

• Metadata: https://your-tenant.b2clogin.com/your-tenant.onmicrosoft.com/B2C_1A_signup_signin_saml/samlp/metadata
• Identity Provider URL: https://your-tenant.b2clogin.com/your-tenant.onmicrosoft.com/B2C_1A_signup_signin_saml/samlp/sso/login
• Entity ID: You defined in TrustFrameworkExtensions.xml (<Item Key="IssuerUri">). For example, https://your-tenant.onmicrosoft.com/quire
• Base64 X.509 certificate: Extract from metadata <X509Certificate> MIIDizCCAnOgAwIBAgIUU9ndt…

Finally, follow the steps in this guide to configure SAML SSO in Quire.

Troubleshooting SSO error

Signing in after member changes email address

If the organization member changes his Quire’s account email address, they will not be able to sign into Quire using the newly changed email address until it has been updated to the identity provider.

In this case, the organization admin must update the newly changed email address in the identity provider.

Frequently Asked Questions

1. What are some SSO providers that Quire works with?

   Quire currently works with Okta and OneLogin.

2. Can I let my clients access Quire via SSO with their preferred social media platform? How can it be done?

   Yes, this can be done by connecting Quire with the SSO provider Microsoft Azure AD B2C. When connected correctly, your clients can use their preferred social media (Facebook, Twitter, Linkedin, etc) or their local account identities to get SSO access to your applications.

3. I am running into several issues while setting up my connection between my SSO provider and Quire. How can I reach out for help?

   There are two main ways to reach out to the Quire support team. In the Quire workspace, you can click on the ? icon at the upper right corner to message the Quire support team or you can email us at feedback@quire.io.

Read more on our blog about Single sign-on with Quire.