お客様のIDプロバイダーでユーザーをサインインさせる

動作

• 組織ごとに 1 つの接続。 組織の管理者が、ダッシュボードの組織設定のシングルサインオンで設定します。
• 誰が使うかはドメインで決まります。 サインインページは最初にメールアドレスを尋ねます。検証済みドメインのアドレスは、そのままプロバイダーに進みます。
• 誰を受け入れるかはプロバイダーが決めます。 そのアドレスを持つアカウントがないユーザーは、接続で Create accounts at first sign-in をオフにしていない限り、最初のサインイン時に作成されます。新しいユーザーは、招待またはプロビジョニングされたグループがプロジェクトを付与するまで、プロジェクトを持ちません。
• お客様のユーザーはメンバーです。 お客様のプロバイダー経由でサインインするユーザーは、お客様の組織のメンバーです。ユーザーを削除できるのはお客様のプロバイダーだけです。
• Require single sign-on は、お客様のドメインでパスワードとパスキーを拒否します。

始める前に

• あなたは組織の管理者です。
• 組織に検証済みドメインがあります。組織設定の確認済みのドメインで、ドメインを追加にドメインを入力し、DNS レコードを取得を選択して、表示された TXT レコードを公開し、続けてexample.com を確認を選択します（example.com の部分にはお客様自身のドメインが入ります）。レコードはそのまま残します。screenRIG はレコードを毎日確認し、レコードが 7 日間見つからないドメインを削除します。削除されると、そのアドレスではシングルサインオンが停止します。
• 接続の変更にはパスキーまたはパスワードが求められます。代わりに、シングルサインオンのセッションが 10 分間、直近のサインインとして扱われますが、これはユーザーがいつ認証されたかをプロバイダーが示す場合（OpenID Connect では auth_time、SAML では AuthnInstant）に限られます。示さない場合は、変更の前に screenRIG がユーザーにプロバイダーで再度サインインするよう求めます。

プロバイダーは次の値を求めます：

各接続には独自のリダイレクト URI があります。接続 ID がアドレスの一部になっているためです。接続を保存すると、組織設定のシングルサインオンのID プロバイダー用の値に、接続 ID が入力済みの状態でそれぞれの正確な値が表示されます。

Microsoft Entra ID

Entra プリセットは、OpenID Connect で 1 つのテナントのユーザーをサインインさせます。

1. Microsoft Entra admin center で App registrations を開き、New registration を選択します。名前を付け、Accounts in this organizational directory only を選択します。リダイレクト URI は空のままにします。手順 6 で追加します。
2. Certificates & secrets を開き、クライアントシークレットを作成して、ID ではなくその Value を今すぐコピーします。
3. Token configuration を開き、Add optional claim を選択し、タイプ ID を選んで email と、あわせて auth_time を追加します。auth_time がないと、Entra はユーザーがいつ認証されたかを示さず、機密性の高い操作ではユーザーが Entra に戻って再度サインインすることになります（ユーザーに表示される内容を参照）。
4. Overview で Application (client) ID と Directory (tenant) ID をコピーします。
5. 組織設定のシングルサインオンで、シングル サインオンを設定を選択し、続けて Microsoft Entra ID を選択します。サインインページでユーザーに表示される名前、テナント ID、クライアント ID、クライアントシークレットを入力し、接続を保存を選択します。
6. ID プロバイダー用の値で、リダイレクト URI（接続 ID を含む https://screenrig.ai/api/sso/oidc/CONNECTION_ID/callback）をコピーします。Entra では Authentication を開き、プラットフォーム Web を追加し（Single-page application ではありません。コード交換は当社のサーバーで実行されます）、その値を入力します。
7. テストサインインを実行します。

screenRIG はユーザーを Entra のオブジェクト ID で識別し、Entra の管理者が編集できるメールアドレスやユーザープリンシパル名では識別しません。ユーザーの名前を変更してもアカウントは維持されます。他のテナントのトークンは拒否されます。screenRIG は email クレームからアドレスを読み取り、Entra テナントでは preferred_username にフォールバックします（email がない場合）。手順 3 のオプションクレームが、これをユーザーのメールアドレスにします。Entra は email_verified を送信しないため、screenRIG はアドレスがお客様の検証したドメインのものであることを根拠に受け付けます。エンタープライズアプリケーションの Assignment required が Yes でない限り、Entra はテナントのすべてのユーザーのサインインを許可します。

Okta とその他の OpenID Connect プロバイダー

これは Okta、Auth0、Keycloak、および /.well-known/openid-configuration にディスカバリードキュメントがあるすべてのプロバイダーに適しています。

1. プロバイダーで、認可コードフローを使用するウェブアプリケーションを作成します。Okta では、Applications、Create App Integration、OIDC、Web Application を選択します。screenRIG がお客様用のリダイレクト URI を用意する前にプロバイダーがそれを求める場合は、今は任意の https アドレスを入力し、手順 4 で置き換えます。サインインを許可するユーザーまたはグループを割り当てます。
2. クライアント ID、クライアントシークレット、発行者（ディスカバリードキュメントに記載された https アドレス）をコピーします。Okta では、https://example.okta.com のような組織の URL、またはカスタム認可サーバーのアドレスです。
3. 組織設定のシングルサインオンで、シングル サインオンを設定を選択し、続けて OpenID Connect を選択します。名前、発行者、クライアント ID、クライアントシークレットを入力し、接続を保存を選択します。
4. ID プロバイダー用の値で、リダイレクト URI（接続 ID を含む https://screenrig.ai/api/sso/oidc/CONNECTION_ID/callback）をコピーし、プロバイダーでアプリケーションのリダイレクト URI として入力します。
5. テストサインインを実行します。

プロバイダーは、S256 による PKCE、form_post レスポンスモード、非対称アルゴリズムで署名された ID トークンに対応している必要があり、openid、email、profile のスコープを許可している必要があります。その ID トークンには email クレームが含まれている必要があります。別のクレームにフォールバックするのは Entra テナントのみです。email_verified クレームが送信される場合は true でなければなりません。プロバイダーが対応できる場合は auth_time クレームを送信してください。screenRIG はこれによって、ユーザーがいつ認証されたかを把握します。

SAML 2.0

これは Entra のエンタープライズアプリケーション、Okta、Google Workspace、およびその他の SAML 2.0 プロバイダーに適しています。まずプロバイダー側で始め、そのメタデータを screenRIG に入力します。screenRIG にはプロバイダーが必要とする値が表示されます。

screenRIG は、各レスポンスが次の条件を満たすことを要求します：

• レスポンスにはアサーションがちょうど 1 つ含まれ、暗号化されていません。
• アサーション自体が、RSA または ECDSA と SHA-256 以上で署名されています。SHA-1 は拒否され、署名されていないアサーションを署名されたレスポンスで包んだものも拒否されます。
• アサーションの発行者はプロバイダーのエンティティ ID で、そのオーディエンス制限には screenRIG のエンティティ ID が指定されています。
• サインインは screenRIG から始まります。プロバイダーのアプリポータルのタイル（IdP 起点のサインイン）は拒否されます。ユーザーは screenRIG のサインインページから始めます。
• 時計のずれは 3 分以内で、各アサーションは一度だけ使用されます。
• NameID が存在し、形式が persistent、メールアドレス、または unspecified です。transient の NameID と、その他の形式は拒否されます。NameID は screenRIG におけるユーザーの識別子で、Entra ではオブジェクト ID 属性です。
• メールアドレスは、属性 email、mail、urn:oid:0.9.2342.19200300.100.1.3、http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress または http://schemas.xmlsoap.org/ws/2005/05/identity/claims/upn として、またはメール形式の NameID として届きます。

Entra ID

1. Enterprise applications、New application、Create your own application の順に開き、Integrate any other application you don't find in the gallery を選択します。
2. Single sign-on を開き、SAML を選択します。SAML Certificates で Federation Metadata XML をダウンロードし、Signing Option を Sign SAML assertion または Sign SAML response and assertion に設定します。
3. 組織設定のシングルサインオンで、シングル サインオンを設定を選択し、続けて SAML 2.0 を選択します。名前を入力し、メタデータ XML をメタデータドキュメントに貼り付けて、接続を保存を選択します。すると、ID プロバイダー用の値にエンティティ IDとアサーション コンシューマー サービス (ACS) アドレスが表示されます。
4. Entra で Basic SAML Configuration を編集します。Identifier はエンティティ ID、Reply URL は ACS アドレスです。
5. デフォルトのクレームはそのままにします。これらにはユーザーのオブジェクト ID とメールアドレスが含まれます。割り当てるユーザーにメールアドレスがあることを確認します。
6. Users and groups でユーザーを割り当て、テストサインインを実行します。

OpenID Connect ですでにサインインしているユーザーは、テナントが SAML に移行してもアカウントを維持し、その逆の場合も同様です。どちらのプロトコルも、テナントと Entra のオブジェクト ID でユーザーを識別するためです。SAML レスポンスにはオブジェクト識別子クレームを含める必要があり、Entra の既定のクレームには含まれています。含まれていない場合、screenRIG は NameID にフォールバックし、OpenID Connect でリンクされたアカウントは一致しなくなります（subject_mismatch）。

Okta

1. Applications、Create App Integration、SAML 2.0 の順に選択します。Okta はメタデータを表示する前に Single sign-on URL と Audience URI を求めます。ここでは両方に任意の https アドレスを入力します。
2. Name ID format を Persistent、Application username を Email に設定し、属性ステートメント email を値 user.email で追加します。Show Advanced Settings で、Assertion Signature は Signed のまま、Signature Algorithm は RSA-SHA256、Digest Algorithm は SHA256 にし、Assertion Encryption はオフにします。
3. Finish を選択し、Sign On タブを開いて、Identity Provider metadata をコピーします。
4. 組織設定のシングルサインオンで、シングル サインオンを設定を選択し、続けて SAML 2.0 を選択します。名前を入力し、メタデータをメタデータドキュメントに貼り付けて、接続を保存を選択します。エンティティ IDとアサーション コンシューマー サービス (ACS) アドレスをID プロバイダー用の値からコピーします。
5. Okta で SAML Settings を編集します。Single sign-on URL は ACS アドレス、Audience URI はエンティティ ID です。
6. ユーザーを割り当ててから、テストサインインを実行します。

Google Workspace

1. Admin console で Apps、Web and mobile apps、Add app の順に開き、Add custom SAML app を選択します。名前を付けます。
2. Google Identity Provider のメタデータをダウンロードして続行します。
3. 組織設定のシングルサインオンで、シングル サインオンを設定を選択し、続けて SAML 2.0 を選択します。名前を入力し、メタデータをメタデータドキュメントに貼り付けて、接続を保存を選択します。エンティティ IDとアサーション コンシューマー サービス (ACS) アドレスをID プロバイダー用の値からコピーします。
4. Google で、ACS アドレスとエンティティ ID を入力します。Name ID format を PERSISTENT、Name ID を Basic Information, Primary email に設定します。Signed response はチェックを外したままにします。この場合、Google がアサーションに署名します。screenRIG はこれを必須としています。
5. Google Directory の属性 Primary email を、アプリの属性 email にマッピングします。
6. アプリの User access を開き、サインインするユーザーに対してオンにしてから、テストサインインを実行します。

証明書をローテーションする

接続は最大 4 つの署名証明書を信頼するため、ローテーション中に空白期間は生じません。古い証明書の隣に新しい証明書を貼り付け（または両方が記載されたプロバイダーの新しいメタデータを貼り付け）て保存し、プロバイダーを新しい証明書に切り替えてから、古い証明書を削除します。

Test sign-in

組織設定でテストサインインを押します。プロバイダーでサインインしてダッシュボードに戻ると、プロバイダーが送信したアドレスと、安定した識別子が送信されたかどうかが表示されます。テストでは誰もサインインされません。テストに失敗すると、いずれかのエラーコードに対応するメッセージが表示されます。アドレスは検証済みドメインのものである必要があります。

接続の現在のプロバイダー、テナント、エンティティ ID、プロトコルでテストまたは実際のサインインに成功すると、シングルサインオンを必須にできます。

Require single sign-on

テストに成功したら、組織設定でシングル サインオンを必須にするを選択し、ブレークグラス管理者を選んで確定します。検証済みドメインのすべてのユーザーに対して、次のようになります：

• サインインページにはプロバイダーのみが表示されます。パスワードまたはパスキーは sso_required で拒否されます。パスワードとパスキーは使用されないままアカウントに残り、要件をオフにすると再び使えます。
• 検証済みアドレスがお客様のドメインにある既存のアカウントは、どのサインイン方法を持っていても、最初のシングルサインオンで同じアカウントにサインインし、プロジェクトを維持します。その後は、お客様の組織がそのアカウントを管理します。メールアドレスはサインインのたびにプロバイダーに合わせて更新され、ユーザー本人は変更できません。
• ブレークグラス管理者。 パスキーを持つ組織の管理者を最大 2 人選びます。プロバイダーが停止した日に備えて、この管理者はパスキーでのサインインを維持でき、そのサインインはすべて記録されます。緊急アクセス用管理者を変更で、あとから選択を変更できます。
• 要件がオンの間は、接続の発行者、テナント ID、エンティティ ID、プロトコルを変更できず、接続を削除することもできません。証明書とクライアントシークレットはローテーションできます。

オフにするには 72 時間かかります。 Turn off requirement を選択します。それまでこの要件は有効なままで、すべての管理者にメールが送信され、どの管理者も Cancel removal を選択できます。

ユーザーに表示される内容

• サインインページは最初にメールアドレスを尋ね、プロバイダーに進みます。結果はドメインのみで決まるため、ユーザーがアカウントを持っているかどうかはわかりません。
• セッションは screenRIG でのサインインから 24 時間続き、利用しても延長されません。12 時間後は、次のページでダッシュボードが操作なしで自動的に更新し、セッション終了後も同じ方法で再びサインインします。操作なしでの開始ではログインヒントが送信されないため、プロバイダーはセッションを保持しているアカウントとして応答します。それが別のユーザーである場合、更新は subject_mismatch で失敗します。プロバイダーのセッションが有効なユーザーは何も入力する必要がありません。そうでない場合は、再度サインインします。
• 接続の変更など、パスキーまたはパスワードを求める操作では、代わりに、直近のサインインとして 10 分間扱われるシングルサインオンのセッションが受け付けられます。これが認められるのは、ユーザーがいつ認証されたかをプロバイダーが示す場合に限られます。対象となるのはプロバイダー自身の時刻（OpenID Connect では auth_time、SAML では AuthnInstant）であり、screenRIG でのサインイン時刻ではありません。プロバイダーが時刻を示さない場合、または 10 分より古い時刻を示す場合、screenRIG はユーザーにプロバイダーで再度サインインするよう求めます。ダッシュボードはユーザーをプロバイダー経由で新たに認証させ、元の場所に戻します。
• プロバイダーで無効にされたユーザーは 24 時間以内にアクセスを失い、ユーザープロビジョニングを使うと直ちに失います。ユーザーが承認したエージェントと OAuth グラントは、ユーザープロビジョニングまたは screenRIG スタッフによってそのユーザーが無効化されるまで動作し続けます。シングルサインオンの必須化や、プロバイダーでのユーザーの無効化では終了しません。

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

検証済みドメインのユーザーがすでにパスワードまたはパスキーを持つ screenRIG アカウントを持っている場合、シングルサインオンを必須にしていない限り、最初のシングルサインオン（account_exists）ではそのアカウントにサインインしません。ユーザーはこれまでどおりサインインし、プロフィールとサインイン（https://screenrig.ai/dashboard/me）を開き、シングル サインオンを連携を選択して、プロバイダーでサインインします。以降は、シングルサインオンで同じアカウントが開き、そのアカウント独自のサインイン方法は維持されます。プロフィールとサインインでは、ドメインのサインイン済みのユーザーのうち、まだリンクしていないすべてのユーザーにリンクが表示されます。

トラブルシューティング

サインインに失敗すると、アドレスにコード（#sso_error=CODE）が付いた状態でサインインページに戻ります。テストに失敗すると、接続にそのコードに対応するメッセージが表示されます。

関連

• ユーザープロビジョニング：プロバイダーからユーザーを作成、更新、削除し、グループにプロジェクトへのアクセスを付与します。
• 認証：エージェントのサインイン方法とアクセスの承認方法。
• API リファレンス：接続、ポリシー、サインインのルート。