コンテンツへスキップ

シングルサインオン

Tuist は、組織のアカウントセキュリティを強化するためのログインオプションとしてシングルサインオンを提供します。

シングルサインオンは、組織設定の 認証 タブから構成します。Google Workspace、Okta、Microsoft Entra ID、およびカスタム OAuth 2.0 プロバイダーがサポートされています。

Microsoft Entra ID は OpenID Connect プロバイダーであり、Tuist がディレクトリ識別子から自動的に構成します。このガイドでカスタムプロバイダーについて説明している内容（ログイン用メールドメインの検証やエンロールメントなど）は、すべて Microsoft Entra ID にも適用されます。

Note

シングルサインオンは、メンバーの認証方法と、認証済みユーザーが自動的に参加できるかどうかを制御します。System for Cross-domain Identity Management provisioning は、ID プロバイダーが組織メンバーを作成、更新、およびプロビジョニング解除できるかどうかを制御します。Okta の場合、ほとんどの組織で両方を構成します。

アクセスの仕組み#

プロバイダーの識別情報、ログインの検出、組織へのエンロールメントはそれぞれ独立した概念です。

  • プロバイダーの発行元: ユーザーを認証したプロバイダー組織または認可サーバーです。Tuist は、リンクされた ID を検索する際に、プロバイダー、発行元、および安定したプロバイダーユーザー識別子を組み合わせて使用します。Okta の場合、発行元は Okta ドメインで表されます。Microsoft Entra ID の場合、ディレクトリ（テナント）識別子から導出されます。カスタムプロバイダーの場合、プロバイダー URL で表されます。
  • ログイン用メールドメイン: Tuist が一般的なログインページから Okta またはカスタムプロバイダーを検出するために使用するメールドメインです。検証が完了すると、新しいアカウントのリンクと自動エンロールメントで信頼できるメールアドレスも確立されます。
  • エンロールメントポリシー: 信頼されたドメインのユーザーが招待を必要とするか、自動的に参加できるかを決定します。
  • プロビジョニング: ログインフローとは独立して組織メンバーシップを作成および管理します。

プロバイダーの発行元とログイン用メールドメインは異なることがよくあります。例えば、企業は従業員用のメールに example.com を使用している一方で、プロバイダーの発行元は https://login.vendor.example.net である場合があります。新しい Okta およびカスタムプロバイダーの構成では、これらの値は個別に保存されます。

ログイン用メールドメインの検証#

Okta およびカスタムプロバイダーの構成では、新しい Tuist アカウントを作成したり、既存のアカウントをメールアドレスでリンクしたりする前に、ログイン用メールドメインの検証が必要です。ドメインが未検証の間でも、メンバーは 既存のアカウントをリンク できます。

  1. ログイン用メールドメイン に、example.com などの従業員用メールドメインを入力します。
  2. シングルサインオンの構成を保存します。
  3. Tuist が表示する TXT レコードを、ドメインの Domain Name System 構成に追加します。
  4. 認証設定に戻り、ドメインを検証 をクリックします。

検証済みのログイン用メールドメインは、1 つの Tuist 組織のみに関連付けることができます。ドメインを変更すると検証がクリアされ、新しい TXT レコードの公開が必要になります。ドメインが検証されるまで、自動エンロールメントは一時停止されたままになります。

Tuist は毎日 TXT レコードを再確認します。レコードの解決が停止しても、検証はすぐにクリアされません。ドメインは 14 日間それを保持し、認証設定には 検証の有効期限切れ と、再度公開すべきレコードが表示されます。レコードを公開して検証を行うと、警告はクリアされます。14 日後もレコードが見つからないドメインは未検証の状態に戻り、プロバイダーの検出、ID のリンク、自動エンロールメントは再び検証されるまで停止します。他の理由でルックアップが失敗しても、タイマーはリセットされず、検証自体はクリアされません。毎日再確認が導入される前に検証されたドメインは、再確認の対象ではありません。

Google Workspace は、認証された ID の一部として検証済みの Workspace ドメインを Google が提供するため、この個別の Tuist 検証手順を必要としません。

エンロールメントポリシーの選択#

Tuist は 2 つのエンロールメントポリシーをサポートしています。

  • 招待のみ: ユーザーには組織からの招待が必要です。Okta およびカスタムプロバイダーの場合、プロバイダーが新しい Tuist アカウントを作成する前に、ログイン用メールドメインの検証が完了している必要があります。既存の Tuist アカウントを持つ招待されたユーザーは、まず招待を受け入れ、その後 既存の Tuist アカウントをリンク で説明されている手順に従ってプロバイダー ID をリンクします。
  • 自動: 認証されたメールが信頼されたドメインと一致するユーザーは、招待なしでアカウントを作成またはリンクし、組織に参加できます。Google の構成では Workspace ドメインを使用します。Okta およびカスタムプロバイダーでは、検証済みのログイン用メールドメインが必要です。

Google の構成はデフォルトで自動エンロールメントになります。新しい Okta およびカスタムプロバイダーの構成は、デフォルトで招待のみによるエンロールメントになります。

シングルサインオンを強制 設定はエンロールメントとは独立しています。組織の保護されたブラウザページへのアクセスには、現在のプロバイダーと発行元（または検証済みの Google Workspace）を通じて認証されたセッションが必要です。過去にリンクされた ID や、別の組織のプロバイダーを通じた認証では不十分です。Tuist への通常のサインインや他のアカウントへのアクセスは引き続き利用可能であり、強制によって組織メンバーシップが付与されるわけではありません。匿名の公開ダッシュボードと時間制限付きのオペレーターサポート権限は、それぞれ独自のアクセスルールを維持します。アプリプレビューページでは組織メンバーに対してのみ強制が適用されるため、組織外で共有されたプレビューリンクは、訪問者がすでに開くことのできたプレビューに対して引き続き機能します。

強制は、メンバーのセッションが組織に到達するあらゆる場所で適用されます。

  • ダッシュボード: 組織のページと、WebMCP を介してブラウザエージェントに提供するツールは、組織のプロバイダーでサインインしたセッションを必要とします。
  • Tuist CLI、Tuist アプリ、MCP クライアント、および API リファレンス: これらにサインインすると、すべての組織でメンバーに代わって動作する認証情報が作成されるため、シングルサインオンを強制する組織を通じてサインインしたセッションが必要です。Tuist は、別の方法でサインインしたメンバーをまずプロバイダーに送り、メールとパスワードまたは Apple によるサインインを拒否します。これらのクライアントが認証情報を更新するたびに、Tuist は再度確認します。組織のシングルサインオンを通じて取得した認証情報は更新され続け、以前に組織のプロバイダーを通じてサインインしたメンバーが別の方法で取得した認証情報も同様に更新され続けます。その他の認証情報（例えば、組織がシングルサインオンを強制する前にメンバーがパスワードで取得したもの）は、強制下での初回更新から4週間更新され続けます。その後、クライアントはメンバーに再度サインインを求めます。その期間中にダッシュボードまたは tuist auth login を介してプロバイダーを通じてサインインすると、更新が続行されます。

シングルサインオンを強制する複数の組織に所属するメンバーは、1つのセッションが1つの組織を通じてサインインするため、CLI、アプリ、または MCP クライアントにサインインできません。

エンロールされたメンバーが取得する役割を選択する#

自動参加するメンバーは、エンロールされたメンバーの役割 で設定された 役割 を取得します。管理者が変更しない限り、これは user です。viewer に設定すると、ディレクトリ内の全員にサインインを開放しつつ、全員に変更権限を与えることはありません。

この設定は admin に設定できず、SCIM 経由で役割なしでプロビジョニングされたメンバーおよびサインインするメンバーに適用され、管理者が手動で設定した役割を上書きすることはありません。

既存の Tuist アカウントをリンクする#

リンクされたプロバイダー ID は、アカウントが属する他のすべての組織を含め、Tuist アカウント全体にサインインします。Okta およびカスタムプロバイダーの場合、Tuist は、メールアドレスが検証済みのログイン用メールドメインにある場合、または組織の SCIM プロビジョニングによってアカウントが作成された場合にのみ、既存のアカウントを自動的にリンクします。

資格のないアカウントを持つメンバーは、自身で ID をリンクします:

  1. アカウントの通常のサインイン方法で Tuist にログインします。
  2. ID プロバイダー（そのアプリケーションタイルなど）から Tuist を開くか、シングルサインオンを強制している場合は組織のプロジェクトの1つを開きます。
  3. Tuist が表示する組織と ID プロバイダーアカウントを確認し、アカウントをリンク をクリックします。

サインアウト状態でシングルサインオンを開始したメンバーは、まずログインするように求められ、その後 Tuist は確認画面に戻ります。リンクはドメインの検証に依存しないため、メンバーはドメインが検証される前にシングルサインオンを使用できます。

既存の組織#

すべての Okta およびカスタムプロバイダー組織は、検証済みドメインモデルを使用します。一時的な互換モードは削除されました。

ログイン用メールドメインが未検証の場合:

  • 既存のリンク済みメンバーはサインインを継続でき、既存の SSO 強制は組織メンバーに引き続き適用されます。
  • ログインページは、既存の組織メンバーシップのみを通じてプロバイダーを検出します。
  • 自動エンロールメントは一時停止され、プロバイダーは招待があっても新しい Tuist アカウントを作成できません。
  • リンクされていないメンバーは、既存の Tuist アカウントにサインインし、上記のようにリンクを確認します。組織の SCIM プロビジョニングによって作成されたアカウントは、最初の SSO サインイン時に依然としてリンクできます。
  • 新規登録者は、メールアドレスがあなたのドメインを使用しているという理由だけで、あなたのプロバイダーを使用する必要はありません。

既存の有効なエンロールメントおよび強制設定は保存されたままになり、オフにすることができます。管理者はドメインが未検証の間も構成を編集できます。いずれかの設定を有効にするには検証が必要です。その設定が有効な場合、検証により一致するメールアドレスに対する自動エンロールメントが再開されます。Google Workspace の動作は変更されません。

ログイン用メールドメイン は、組織のメンバーからすでに入力されている可能性があります。値を確認し、テキストレコードを公開して、ドメインを検証 をクリックします。毎日再チェックするためにレコードを公開したままにしてください。

Google Workspace#

Google Workspace シングルサインオンは、Workspace ドメインに対してユーザーを認証します。管理者は、一致するユーザーの自動参加を許可するか、招待を要求するかを選択できます。

前提条件

検証済みドメインを持つ Google Workspace 組織が必要です。また、設定中のドメインに関連付けられたメールを使用して Google で認証されている必要があります。

セットアップ#

  1. 組織の 認証 設定タブに移動します。
  2. シングルサインオンを有効にします。
  3. プロバイダーとして Google を選択します。
  4. Google Workspace ドメイン（例: example.com）を入力します。
  5. 自動エンロールメント または招待のみによるエンロールメントを選択します。Google の場合、自動エンロールメントはデフォルトで有効になっています。
  6. ログインフローをテストした後、オプションで シングルサインオンを強制 を有効にします。
  7. 変更を保存 をクリックします。

Okta#

Okta は OpenID Connect を使用してメンバーを認証します。Okta ドメインはプロバイダーの発行元を識別し、別途検証されたログイン用メールドメインは検出、新しいアカウントのリンク、およびエンロールメントを制御します。

Okta によるメンバーの自動作成、更新、またはプロビジョニング解除も希望する場合は、シングルサインオンが機能した後で Okta System for Cross-domain Identity Management provisioning を構成します。

ステップ 1: Okta アプリケーションを作成する#

  1. Okta 管理ダッシュボードで、Applications > Applications > Create App Integration に移動します。
  2. OpenID Connect と Web Application を選択します。
  3. アプリケーション名（例: Tuist）を設定します。オプションで Tuist ロゴ をアップロードできます。
  4. Sign-in redirect URI に、認証設定ページに表示される値（例: https://tuist.dev/users/auth/okta/callback）を設定します。
  5. Assignments で、希望するアクセス制御を選択して保存します。
  6. アプリケーションの一般設定から Client ID と Client Secret をコピーします。Okta ドメイン（例: your-company.okta.com）を控えておきます。
  7. オプションとして、Okta ダッシュボードからのログインを許可するには、General Settings で Edit をクリックし、Login initiated by を Either Okta or App に変更し、Display application icon to users を選択して、Initiate login URI に認証設定ページに表示される値を設定します。

ステップ 2: Tuist を構成する#

  1. 組織の 認証 設定タブに移動します。
  2. シングルサインオンを有効にします。
  3. プロバイダーとして Okta を選択します。
  4. Okta ドメイン、Client ID、および Client Secret を入力します。
  5. ログイン用メールドメイン に従業員のメールドメインを入力します。例えば、Okta ドメインが your-company.okta.com の場合、ログイン用メールドメインは example.com になります。
  6. 変更を保存 をクリックします。
  7. Tuist が表示する TXT レコードをログイン用メールドメインに追加し、ドメインを検証 をクリックします。
  8. ユーザーに招待が必要か、自動エンロールメントを許可するかを選択し、設定を再度保存します。
  9. ログインフローをテストした後、オプションで シングルサインオンを強制 を有効にします。

ステップ 3: ユーザーを Okta アプリケーションに割り当てる#

Okta アプリケーションを通じて認証を許可すべきユーザーまたはグループを割り当てます。

割り当てによりログインフローへのアクセス権が付与されますが、組織メンバーシップは引き続きエンロールメントポリシーに従います。同じユーザーが System for Cross-domain Identity Management 経由でプロビジョニングされている場合、Tuist はユーザーが初めてサインインした際に、SCIM が作成したアカウントに Okta ID をリンクします。SCIM による追加前にアカウントが存在していたメンバーは、メールアドレスが検証済みのログイン用メールドメインに含まれている場合、またはサインイン済みアカウントからリンクを確認した後にリンクされます。

Microsoft Entra ID#

Microsoft Entra ID は OpenID Connect を介してメンバーを認証します。Tuist はディレクトリ（テナント）識別子から承認、トークン、およびユーザー情報エンドポイントを導出するため、アプリケーションの資格情報とともにその値を入力するだけで済みます。

Entra ID によるメンバーの自動作成、更新、またはプロビジョニング解除も希望する場合は、シングルサインオンが機能した後で Microsoft Entra ID System for Cross-domain Identity Management provisioning を構成します。

ステップ 1: Entra アプリケーションを登録する#

  1. Microsoft Entra admin center で、Identity > Applications > App registrations > New registration に移動します。
  2. アプリケーション名（例: Tuist）を設定します。
  3. Redirect URI で、Web プラットフォームを選択し、認証設定ページに表示される値（例: https://tuist.dev/users/auth/oauth2/callback）を入力します。
  4. アプリケーションを登録し、概要ページから Directory (tenant) ID と Application (client) ID をコピーします。
  5. Certificates & secrets > New client secret に移動し、シークレットを作成してその Value をコピーします。Microsoft は値を一度しか表示せず、すべてのクライアントシークレットには有効期限があるため、回転が必要な時期を記録しておきます。
  6. API permissions に移動し、委任された Microsoft Graph 権限 openid、profile、および email が付与されていることを確認します。
  7. オプションとして、メンバーが My Apps ポータルからサインインフローを開始できるようにするには、Branding & properties の下の Home page URL に、認証設定ページに表示される値を設定します。

ステップ 2: Tuist を構成する#

  1. 組織の 認証 設定タブに移動します。
  2. シングルサインオンを有効にします。
  3. プロバイダーとして Microsoft Entra ID を選択します。
  4. Directory (tenant) ID、Client ID、および Client Secret を入力します。
  5. ログイン用メールドメイン に従業員のメールドメインを入力します。例えば、ユーザーが [email protected] としてサインインするディレクトリのログイン用メールドメインは example.com です。
  6. 変更を保存 をクリックします。
  7. Tuist が表示する TXT レコードをログイン用メールドメインに追加し、ドメインを検証 をクリックします。
  8. ユーザーに招待が必要か、自動エンロールメントを許可するかを選択し、設定を再度保存します。
  9. ログインフローをテストした後、オプションで シングルサインオンを強制 を有効にします。

ステップ 3: ユーザーを Entra アプリケーションに割り当てる#

認証を許可するユーザーまたはグループを割り当てます。アプリケーションが割り当てを必須とするように構成されている場合、割り当てられたユーザーのみがサインインできます。

割り当てによりログインフローへのアクセスが付与されますが、組織のメンバーシップは引き続きエンロールメントポリシーに従います。同じユーザーが System for Cross-domain Identity Management 経由でプロビジョニングされている場合、Tuist はユーザーが初めてサインインした際に SCIM が作成したアカウントに Entra ID をリンクします。SCIM による追加前にアカウントが存在していたメンバーは、メールアドレスが検証済みのログイン用メールドメインに含まれている場合、またはサインイン済みのアカウントからリンクを確認した後にリンクされます。

email クレームの要件#

Tuist は Microsoft Graph のユーザー情報エンドポイントから認証済みユーザーのプロファイルを読み取りますが、このエンドポイントはユーザーに利用可能なメールアドレスがある場合にのみ返します。mail 属性が空のディレクトリユーザーは、Tuist がログイン用メールドomainと照合するアドレスを持たないため、サインインできません。

シングルサインオンを展開する前に、割り当てるメンバーのメールアドレスがディレクトリに入力されていることを確認してください。メールボックスを持たないオンプレミスの Active Directory から同期されたユーザーは、この属性が欠落している最も一般的なケースです。

Conditional Access と多要素認証#

Conditional Access ポリシー、多要素認証、およびサインインリスクポリシーは、認可リクエスト中に評価されるため、他の Entra アプリケーションと同様に Tuist アプリケーションにも適用されます。Tuist の追加構成は不要です。

カスタム OAuth 2.0 プロバイダー#

カスタム OAuth 2.0 プロバイダーを使用すると、組織は Google Workspace や Okta 以外の ID サービスを利用できます。プロバイダーのユーザー情報エンドポイントは、安定したユーザー識別子とメールアドレスを返す必要があります。

  1. プロバイダーで OAuth 2.0 ウェブアプリケーションを作成します。
  2. Sign-in redirect URI およびオプションの Initiate login URI を、Tuist の認証設定に表示される値に設定します。
  3. Tuist でシングルサインオンを有効にし、OAuth2 を選択します。
  4. プロバイダー URL、認可エンドポイント、トークンエンドポイント、ユーザー情報エンドポイント、クライアント識別子、およびクライアントシークレットを入力します。
  5. ログイン用メールドメイン を入力して保存します。これは従業員のメールドメインであり、プロバイダー URL ではありません。
  6. Tuist が表示する TXT レコードをログイン用メールドメインに追加し、ドメインを検証 をクリックします。
  7. 招待制または自動エンロールメントを選択し、設定を保存します。
  8. オプションで シングルサインオンを強制 を有効にする前に、サインインをテストします。

プロバイダー URL は ID を発行元プロバイダーに限定します。検証済みのログイン用メールドメインは、ユーザーのリンクまたはエンロールメント時に Tuist が信頼するメールアドレスを決定します。

コマンドライン構成#

コマンドラインインターフェースは Google Workspace または Okta を構成し、エンロールメントポリシーを選択できます。例:

bash
tuist organization update sso example \
--provider okta \
--organization-id your-company.okta.com \
--enrollment-policy invitation-only

Microsoft Entra ID とカスタムプロバイダーは、コマンドラインではなく組織の認証設定から構成します。

--organization-id 値はプロバイダー組織を識別します。これはログイン用メールドメインではありません。新しい Okta ユーザーをエンロールする前に、組織の認証設定からログイン用メールドメインを追加して検証してください。

トラブルシューティング#

既存のメンバーはサインインできますが、新規ユーザーはできません#

Okta およびカスタムプロバイダーの構成では、ログイン用メールドメインが検証済みであることを確認してください。その後、ユーザーを招待するか、自動エンロールメントを有効にします。

シングルサインオンで最初にログインするよう求められます#

Tuist アカウントのメールアドレスが組織の検証済みログイン用メールドメインに含まれていないか、ドメインがまだ検証されていないため、Tuist はプロバイダー ID を自動的にリンクしません。通常のサインイン方法でログインし、既存の Tuist アカウントをリンク で説明されているようにリンクを確認してください。

Tuist がメールアドレスに対応する組織を見つけられません#

ユーザーが想定される従業員のメールアドレスを入力し、そのドメインが検証済みのログイン用メールドomainと完全に一致することを確認してください。既存のメンバーは、現在の組織メンバーシップを通じて発見されることもあります。

ドメイン検証が保留中です#

TXT レコードの名前と値が Tuist に表示される値と完全に一致することを確認してください。DNS の変更には伝播に時間がかかることがあるため、レコードが公開されてから検証を再試行してください。

プロバイダーを変更した後、サインインが停止しました#

新しいプロバイダーの構成を確認し、ログイン用メールドメインを検証してから、強制を有効にする前にログインフローをテストしてください。