Quire의 통합 로그인 (SSO) Permalink

✦
AI 번역
· 영어로 보기

통합 로그인 (SSO)은 Enterprise 플랜에서만 사용할 수 있습니다. 자세한 내용은 요금제 페이지에서 확인할 수 있습니다.

Quire의 통합 로그인 (SSO)을 사용하면 멤버가 SAML 2.0을 통해 중앙화된 아이디 공급자(IdP)로 인증할 수 있습니다. 지원되는 공급자에는 Okta, OneLogin, Azure AD B2C 및 기타 SAML 2.0 호환 IdP가 포함됩니다.

SSO 개요

SSO를 사용하면 사용자가 별도의 Quire 비밀번호를 관리하는 대신 아이디 공급자를 통해 하나의 자격 증명으로 Quire에 로그인할 수 있습니다.

Quire 조직에서 SSO가 활성화되면:

  • 멤버는 회사 아이디 공급자를 사용하여 로그인합니다
  • 별도의 Quire 비밀번호가 필요하지 않습니다
  • 인증이 중앙화되어 더욱 안전합니다
  • IT 관리자의 로그인 관리가 간소화됩니다


Quire는 SAML 2.0 인증을 지원하며 다음과 호환됩니다:

  • Okta
  • OneLogin
  • Azure AD B2C
  • SAML 2.0을 지원하는 모든 IdP


SSO가 활성화되면 조직 멤버는 Quire 비밀번호 대신 IdP를 통해 로그인합니다.

아이디 공급자(IdP) 구성하기

Quire에서 SSO를 활성화하기 전에 먼저 아이디 공급자를 구성해야 합니다.

1단계: SAML 2.0 애플리케이션 만들기

  1. 아이디 공급자 관리자 콘솔에 로그인합니다.
  2. 새 SAML 2.0 애플리케이션을 만듭니다.
  3. 다음 팔로잉 SAML 구성 세부 정보를 입력합니다:
SAML 속성 아이디 공급자에 매핑
https://quire.io/sso/login 애플리케이션의 SAML Assertion Consumer Service (ACS) URL
https://quire.io/sso/metadata 애플리케이션의 SP 개체 아이디
멤버의 이메일 주소 Name ID 형식

2단계: 필요한 SAML 정보 수집하기

애플리케이션을 만든 후 다음 팔로잉 정보를 복사합니다:

  • 아이디 공급자 URL
  • 개체 아이디
  • Base64 X.509 인증서

3단계: 아이디 공급자에서 사용자 할당하기

  1. 새로 만든 Quire SAML 애플리케이션에 사용자 또는 그룹을 추가합니다.
  2. 적절한 접근 권한이 할당되었는지 확인합니다.


SSO로 인증하려면 사용자가 먼저 IdP에 할당되어 있어야 합니다.

Quire에서 SSO 구성하기

1단계: 조직 설정 열기

  1. 조직 이름 옆에 있는 드롭다운 메뉴 아이콘을 클릭합니다.
  2. 옵션을 선택합니다.

조직 설정

2단계: SAML 인증 활성화하기

  1. 보안 탭으로 이동합니다.
  2. SAML 인증을 켭니다.

Quire 조직 보안 설정에서 SAML 인증 활성화하기

3단계: SAML 구성 세부 정보 입력하기

  1. 아이디 공급자 URL을 붙여넣습니다.
  2. 개체 아이디를 입력합니다.
  3. Base64 X.509 인증서를 붙여넣습니다.
  4. SSO 테스트를 클릭하여 설정을 확인합니다.
  5. 성공하면 저장을 클릭합니다.

SAML 구성

필수 SSO와 선택 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
  • 개체 아이디
  • 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
  • 개체 아이디: TrustFrameworkExtensions.xml(<Item Key="IssuerUri">)에서 정의합니다. 예: https://your-tenant.onmicrosoft.com/quire
  • Base64 X.509 인증서: 메타데이터의 <X509Certificate> MIIDizCCAnOgAwIBAgIUU9ndt…에서 추출합니다


그런 다음 Quire에서 SSO 구성하기의 단계를 팔로우하세요.

SSO 문제 해결

멤버가 Quire에서 이메일 주소를 변경하면 아이디 공급자에서 새 이메일이 업데이트되기 전까지 SSO로 로그인할 수 없습니다.

이 문제를 해결하려면:

  1. 아이디 공급자에서 멤버의 이메일 주소를 업데이트합니다.
  2. NameID가 업데이트된 이메일과 일치하는지 확인합니다.
  3. 멤버에게 다시 로그인을 시도하도록 안내합니다.

Quire의 통합 로그인 (SSO)에 대한 자세한 내용은 블로그에서 확인하세요.

자주 묻는 질문

Quire SSO는 어떤 아이디 공급자를 지원하나요?

Okta, OneLogin, Azure AD B2C를 포함한 모든 SAML 2.0 호환 IdP를 지원합니다. SSO는 Enterprise 플랜에서만 사용할 수 있습니다.

Quire에서 SSO를 어떻게 활성화하나요?

Quire의 ACS URL(https://quire.io/sso/login)과 개체 아이디(https://quire.io/sso/metadata)를 사용하여 IdP에서 SAML 2.0 앱을 구성하고, IdP URL, 개체 아이디, 인증서를 수집한 다음 조직 옵션 > 보안 탭으로 이동하여 SAML 인증을 활성화하고 해당 정보를 붙여넣은 후 SSO 테스트를 클릭하고 저장합니다.

Quire 조직에서 SSO를 필수 또는 선택으로 설정할 수 있나요?

예. 필수로 설정하면 모든 멤버가 IdP를 통해 로그인해야 합니다. 선택으로 설정하면 멤버가 Quire 비밀번호 또는 SSO 중에서 선택할 수 있습니다.

Quire에서 조직 관리자도 SSO를 사용해야 하나요?

아니요. 다른 멤버에게 SSO가 필수로 설정된 경우에도 관리자는 항상 Quire 비밀번호로 로그인합니다.

이메일을 변경한 후 멤버가 SSO로 로그인할 수 없을 때는 어떻게 해야 하나요?

아이디 공급자에서 멤버의 이메일을 업데이트하여 NameID가 새 주소와 일치하도록 합니다. 그러면 멤버가 다시 SSO로 로그인할 수 있습니다.

Azure AD B2C SSO에 대해 Quire가 요구하는 NameID 형식은 무엇인가요?

userPrincipalName 또는 email을 사용하세요. objectId는 사용하지 마세요 — 인증 실패의 원인이 됩니다.

고객이 Facebook이나 LinkedIn 같은 소셜 미디어 계정으로 Quire에 로그인할 수 있나요?

예, Azure AD B2C 통합을 통해 가능합니다. 지원되는 공급자에는 Facebook, X(구 Twitter), LinkedIn, Microsoft 계정 및 로컬 아이디 계정이 포함됩니다.

마지막 업데이트:

추가 도움이 필요하시면 문의하기로 연락해 주세요.