Cintoo SSO実装ガイド

この記事では、シングルサインオン（SSO）の利点と選択できるオプション、およびSSOを正しく設定するためにCintooに提供する必要がある情報について説明します。

目次

• 概要
• 認証フロー
• ユーザープロビジョニング
• 外部ユーザー
• SSO実装プロセス
  • オプション1：OpenID Connect
    • カスタムアプリケーションを使用するAzure AD
    • Okta
    • その他のプロバイダー
  • オプション2：SAML

概要

Cintooは、お客様の企業のシングルサインオン（SSO）ソリューションと統合でき、企業のセキュリティ要件を満たしながら、ユーザー管理を簡素化できます。

Cintooは、OpenID Connect（OIDC）およびSAMLプロトコルをサポートしており、次のIDプロバイダーと互換性があります：

• Azure AD（推奨プロバイダー）
• Microsoft ADFS
• Okta / Okta MyID
• Ping Federate

お客様のCintooアカウントでSSOオプションを契約するには、Cintooの営業担当者またはsales@cintoo.comまでお問い合わせください。

認証フロー

Cintooでの認証は、二つのステップで行われます：

• ログイン（メールアドレス）を入力します
• ドメイン名（メールアドレスの@の後の部分）に応じて、Cintooネイティブ認証画面（Cintooのログインとパスワードによる認証）または企業のSSOログイン画面にリダイレクトされます。

つまり、@corp.comドメインでSSOが有効化されると、user@corp.comの形式のログインを持つすべてのユーザーは、対応するIDプロバイダーのログイン画面にリダイレクトされ、Cintooネイティブ認証にフォールバックする方法はありません。

ユーザープロビジョニング

SSOは認証にのみ使用され、Cintooアカウントでのユーザーの作成方法には影響しません。ユーザーは引き続き、アカウント管理者、またはプロジェクト/BIMマネージャーが招待する必要があります。

アカウントに招待されていないユーザーが、SSOを使用して認証しようとしても、ログインできません。

外部ユーザー

外部ユーザー（つまり、お客様が管理していないドメインのメールアドレスを持つユーザー）をプロジェクトに招待した場合、SSOはドメイン名ごとに設定されるため、既定ではこれらのユーザーはお客様のSSOで認証されません。

例：

• お客様の会社のドメイン名はcorp.comです
• user@guest.comをプロジェクトの一つに招待します
• guest.comもCintooのお客様でSSOオプションを契約している場合、user@guest.comはguest.comのSSOで認証されます（corp.comのSSOではありません）。そうでない場合、このユーザーはCintooネイティブ認証でログインします。

外部ユーザーの管理を強化するには、次の方法があります：

• すべての外部ユーザーを、自社のユーザーディレクトリにゲストとして追加します（例：user-guest@corp.com）
• Cintooのカスタムドメイン（つまりhttps://corp.cintoo.cloud）を契約します（詳細はCintooの営業担当者にお問い合わせください）。これにより、お客様専用のCintoo Tenantが提供され、すべてのプロジェクトにはhttps://corp.cintoo.cloudからのみアクセスできるようになります。
• Cintoo ITチームに、カスタムドメインとSSOプロバイダーの紐付けを依頼します。これにより、https://corp.cintoo.cloudでプロジェクトを開こうとするユーザーは、@corp.comのメールアドレスを持っていなくても、お客様のSSOにリダイレクトされます。

SSO実装プロセス

SSOの実装は、常に次の手順で行われます：

• Cintooの営業担当者に連絡して、オプションを契約します
• IDプロバイダーをOIDCまたはSAMLで構成し、必要な情報をsupport@cintoo.com経由でCintoo ITチームに伝えます（詳細は以下を参照）
• 一時的なログインURLを使用して、数人のユーザーでSSO構成を検証します
• Cintoo ITチームと切り替え日について合意します。この日以降、お客様のドメインのすべてのユーザーが、SSOログイン画面にリダイレクトされます

IDプロバイダーの構成

オプション1：OpenID Connect

カスタムアプリケーションを使用するAzure AD

Azure ADで独自のアプリケーションを作成する必要があります。

Azure ADで、App registrations、New registrationの順に選択します

アプリケーションを作成したら、Authentication設定を編集し、ID tokensオプションを有効にします。

アプリケーションのApplication (client) IDとDirectory (tenant) IDを控えて、これらの値をCintooサポートチームに伝えます。

このオプションのクレームを追加する方法は次のとおりです。

メールアドレスを読み取るために、Microsoft Graph用のAPIアクセス許可を追加する必要があります。

Okta

OktaAdministrationで、新しいアプリを作成します。

Web / OpenID Connectを選択します。

必要なリダイレクトURLを追加します。

次の画面のGeneral Settingsで、Editをクリックし、ID Token with implicit grant権限を追加します。

完了したら、Sign Onタブに移動し、OpenID Connect ID TokenセクションのIssuerフィールドとAudienceフィールドを控えます。

これらの値をCintooサポートチームに伝える必要があります。

その他のプロバイダー

OpenID Connectを使用するその他のIDプロバイダーの一般的な構成は次のとおりです：

• Cintooアプリケーションを作成します
• リダイレクトURIを構成します：https:///login/oauthcb。domainは、お客様のCintooインスタンスによって異なります（例：us.cintoo.cloud、eu.cintoo.cloud、ca.cintoo.cloud）。
• ID tokenをimplicit grantで許可します
• 次のスコープを許可します：openID email profile
• 次の情報をCintooサポートチームに伝えます：

1. Client ID
   2. OpenID Connect discovery URL（例：https:///.well-known/openid-configuration）
   注：Cintooは、OAuth応答のemailフィールドに基づいてユーザー名を照合します。emailフィールドがない場合は、代わりにupnフィールドが使用されます。

オプション2：SAML

SAML IDプロバイダー内で構成する必要がある、サービスプロバイダーのメタデータを次に示します。

<md:EntityDescriptor xmlns:md="urn:oasis:names:tc:SAML:2.0:metadata" entityID="https://<domain>/saml"> 
    <md:SPSSODescriptor AuthnRequestsSigned="false" WantAssertionsSigned="false" protocolSupportEnumeration="urn:oasis:names:tc:SAML:2.0:protocol"> 
        <md:NameIDFormat>urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress</md:NameIDFormat> 
        <md:AssertionConsumerService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST" Location="https://<domain>/saml" index="1"/> 
    </md:SPSSODescriptor> 
</md:EntityDescriptor>

IdPのメタデータのURLまたはファイルをCintooサポートチームに伝える必要があります。少なくとも、次の詳細が必要です：

• IDP entity ID
• ログインURL
• 署名証明書