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アサーションコンシューマーサービス（ACS）URL
https://quire.io/sso/metadata アプリケーションのSPエンティティID
メンバーのメールアドレス Name ID形式

ステップ2：必要なSAML情報の収集

アプリケーションを作成したら、以下の情報をコピーします：

  • IDプロバイダーURL
  • エンティティID
  • 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. IDプロバイダーURLを貼り付けます。
  2. エンティティIDを入力します。
  3. Base64 X.509証明書を貼り付けます。
  4. Test 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
  • IDプロバイダーURL
  • エンティティID
  • Base64 X.509証明書


以下は、これらの情報の例です：

  • メタデータ: https://your-tenant.b2clogin.com/your-tenant.onmicrosoft.com/B2C_1A_signup_signin_saml/samlp/metadata
  • IDプロバイダー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…


その後、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）とエンティティID（https://quire.io/sso/metadata）を使用してIdPでSAML 2.0アプリを設定し、IdP URL、エンティティID、証明書を収集したうえで、組織のオプション > セキュリティタブに移動し、SAML認証を有効にして収集した情報を貼り付け、Test 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アカウント、ローカルアイデンティティアカウントがサポートされています。

最新の更新：

サポートが必要な場合は、お問い合わせください。