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での認証は、2つのステップで行われます。

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

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

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

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

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

外部ユーザー

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

例：

• 貴社のドメイン名はcorp.comです
• プロジェクトの1つに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テナントが提供され、すべてのプロジェクトには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

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

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）
• implicit grantを使用したIDトークンを許可します
• 次のスコープを許可します：openID email profile
• 次の情報をCintooサポートチームに連絡します。

1. Client ID
   2. OpenID Connect検出URL（例：https:///.well-known/openid-configuration）

オプション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
• Login URL
• Signing certificate(s)