Единый вход (SSO) в Quire Permalink

✦
Переведено ИИ
· Смотреть на английском

Единый вход (SSO) доступен только в тарифном плане Enterprise. Подробнее — на нашей странице тарифов.

Единый вход (SSO) в Quire позволяет участникам проходить аутентификацию через централизованного поставщика идентификации (IdP) с использованием SAML 2.0. Поддерживаются Okta, OneLogin, Azure AD B2C и любой другой IdP, совместимый с SAML 2.0.

Обзор SSO

SSO позволяет пользователям входить в Quire с помощью единого набора учётных данных через поставщика идентификации, не управляя отдельным паролем Quire.

При включённом SSO для вашей организации Quire:

  • Участники входят через корпоративного поставщика идентификации
  • Отдельный пароль Quire не требуется
  • Аутентификация централизована и более безопасна
  • Управление входом упрощается для IT-администраторов


Quire поддерживает аутентификацию SAML 2.0 и работает с:

  • Okta
  • OneLogin
  • Azure AD B2C
  • Любым IdP с поддержкой SAML 2.0


После включения SSO участники организации будут входить через IdP, а не с помощью пароля Quire.

Настройка поставщика идентификации (IdP)

Перед включением SSO в Quire необходимо сначала настроить поставщика идентификации.

Шаг 1: Создание приложения SAML 2.0

  1. Войдите в консоль администратора своего поставщика идентификации.
  2. Создайте новое приложение SAML 2.0.
  3. Введите следующие данные конфигурации SAML:
Атрибут SAML Сопоставление с вашим поставщиком идентификации
https://quire.io/sso/login URL службы обработки подтверждений SAML (ACS) для приложения
https://quire.io/sso/metadata SP ID субъекта приложения
Адрес электронной почты участника Формат Name ID

Шаг 2: Сбор необходимых данных SAML

После создания приложения скопируйте следующую информацию:

  • URL поставщика идентификации
  • ID субъекта
  • Сертификат Base64 X.509

Шаг 3: Назначение пользователей в поставщике идентификации

  1. Добавьте пользователей или группы в созданное приложение Quire SAML.
  2. Убедитесь, что назначены необходимые разрешения доступа.


Пользователи должны быть назначены в IdP до того, как смогут пройти аутентификацию через SSO.

Настройка SSO в Quire

Шаг 1: Открытие настроек организации

  1. Нажмите на значок раскрывающегося меню рядом с именем организации.
  2. Выберите Параметры.

настройки организации

Шаг 2: Включить аутентификацию SAML

  1. Перейдите на вкладку Безопасность.
  2. Включите аутентификацию SAML.

Включить аутентификацию SAML в настройках безопасности организации Quire

Шаг 3: Ввод данных конфигурации SAML

  1. Вставьте URL поставщика идентификации.
  2. Введите ID субъекта.
  3. Вставьте сертификат Base64 X.509.
  4. Нажмите Тестировать SSO для проверки настройки.
  5. При успешной проверке нажмите Сохранить.

Конфигурация SAML

Обязательный или дополнительный SSO

Вы можете настроить SSO следующим образом:

  • Обязательный — все участники должны входить через SSO.
  • Дополнительный — участники могут входить как с паролем, так и через SSO.

Примечание: Администраторы организации всегда входят с использованием пароля Quire.

После успешной настройки участники больше не будут нуждаться в отдельном пароле Quire.

Интеграция с Azure AD B2C

Шаг 1: Настройка Azure AD B2C

  1. Войдите на портал Azure.
  2. Создайте пользовательские политики.
  3. Зарегистрируйте приложение SAML.
  4. Настройте потоки пользователей для аутентификации.


Следить за подробными инструкциями по настройке можно в официальной документации Microsoft.

Шаг 2: Настройка формата NameID

Quire требует, чтобы формат NameID был:

  • userPrincipalName или
  • email


Не используйте objectId.

При использовании userPrincipalName измените:

  • TrustFrameworkBase.xml
  • SignUpOrSigninSAML.xml


Пример TrustFrameworkBase.xml:

<!-- 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:

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


Если вы планируете изменить формат на email, дополнительные сведения можно найти в этом ресурсе.

Шаг 3: Получение необходимых данных из Azure

После настройки соберите:

  • URL метаданных
  • URL поставщика идентификации
  • ID субъекта
  • Сертификат Base64 X.509


Ниже приведены примеры того, как может выглядеть эта информация:

  • Метаданные: https://your-tenant.b2clogin.com/your-tenant.onmicrosoft.com/B2C_1A_signup_signin_saml/samlp/metadata
  • URL поставщика идентификации: https://your-tenant.b2clogin.com/your-tenant.onmicrosoft.com/B2C_1A_signup_signin_saml/samlp/sso/login
  • ID субъекта: задаётся в TrustFrameworkExtensions.xml (<Item Key="IssuerUri">). Например: https://your-tenant.onmicrosoft.com/quire
  • Сертификат Base64 X.509: извлеките из метаданных <X509Certificate> MIIDizCCAnOgAwIBAgIUU9ndt…


Затем следуйте шагам в разделе Настройка SSO в Quire.

Устранение неполадок SSO

Если участник изменил адрес электронной почты в Quire, он не сможет войти через SSO до тех пор, пока новый адрес не будет обновлён у поставщика идентификации.

Для решения проблемы:

  1. Обновите адрес электронной почты участника у поставщика идентификации.
  2. Убедитесь, что NameID соответствует обновлённому адресу.
  3. Попросите участника попробовать войти снова.

Подробнее читайте в нашем блоге: Единый вход с Quire.

Часто задаваемые вопросы

Какие поставщики идентификации поддерживает SSO в Quire?

Любой IdP, совместимый с SAML 2.0, включая Okta, OneLogin и Azure AD B2C. SSO доступен только в тарифном плане Enterprise.

Как включить SSO в Quire?

Настройте приложение SAML 2.0 в своём IdP, используя ACS URL Quire (https://quire.io/sso/login) и ID субъекта (https://quire.io/sso/metadata), скопируйте URL IdP, ID субъекта и сертификат, затем перейдите в настройки организации на вкладку Безопасность, включите аутентификацию SAML, вставьте эти данные, нажмите Тестировать SSO и сохраните.

Можно ли сделать SSO обязательным или дополнительным для организации в Quire?

Да. Обязательный режим требует, чтобы все участники входили через IdP. Дополнительный позволяет участникам выбирать между паролем Quire и SSO.

Должны ли администраторы организации использовать SSO в Quire?

Нет. Администраторы всегда входят с паролем Quire, даже если SSO задан как обязательный для остальных участников.

Что делать, если участник не может войти через SSO после смены адреса электронной почты?

Обновите адрес электронной почты участника у поставщика идентификации, чтобы NameID соответствовал новому адресу. После этого участник сможет снова войти через SSO.

Какой формат NameID требует Quire для SSO через Azure AD B2C?

Используйте userPrincipalName или email. Не используйте objectId — это приводит к ошибкам аутентификации.

Могут ли клиенты входить в Quire через аккаунты в социальных сетях, например Facebook или LinkedIn?

Да, с помощью интеграции Azure AD B2C. Поддерживаются Facebook, X (ранее Twitter), LinkedIn, учётные записи Microsoft и локальные учётные записи.

Последнее обновление:

Пожалуйста свяжитесь с нами, если вам необходима дополнительная помощь.