SSO でチームをサインインさせる
作るもの
「作るもの」というセクションこのチュートリアルを終えると、次のものが揃っています:
- Control Center サーバーとアイデンティティプロバイダー(例として Okta を使います)の間の SAML 接続
- 初回ログイン時に自動でプロビジョニングされる 1 人のユーザー
- あなたが意図的に選んだワークスペースメンバーシップポリシー
自分で管理するサーバー(サーバー所有者 — インストールのオペレーター)と、設定できる IdP アプリケーションが必要です。所要時間の目安は 20 分です。
1. シングルサインオン設定を開く
「1. シングルサインオン設定を開く」というセクションControl Center にサインインし、設定 → サーバー → シングルサインオンを開きます。画面は SAML と OpenID Connect を切り替えられ、さらに **ユーザープロビジョニング(SCIM)**カードがあります。SAML のままにしておきます。
この画面の内容はすべてサーバー全体に及びます。1 つの IdP がすべてのワークスペースのユーザーを認証するため、編集できるのはサーバー所有者だけです。
2. IdP メタデータを貼り付ける
「2. IdP メタデータを貼り付ける」というセクションOkta でアプリの Sign On タブを開き、メタデータ XML をコピーします(またはダウンロードして、そのファイルの内容を貼り付けます)。Control Center に戻り、IdPメタデータXML に貼り付けて 接続をテストを押します。
トーストには IdP のサインオンエンドポイントが表示されます — メタデータが解析され、証明書が読み取られ、それを基にサーバーがログインリクエストを組み立てられることの証拠です(このテストは、ブラウザーの往復を除くすべてを実行します)。失敗した場合、その XML は完全な EntityDescriptor ではありませんでした(Okta の SAML タブではこれを「Metadata URL」と呼びます。その URL を開いて、配信される内容をコピーしてください)。OpenID Connect では、同じボタンが代わりに発行元のディスカバリドキュメントを確認します。期限切れが近い証明書の検出や、IdP が Control Center を認識しているかどうかの確認も行うには、ステップ 6 のチェッカーを使ってください。
3. IdP に Control Center を登録する
「3. IdP に Control Center を登録する」というセクションSPメタデータをコピーを押し、Okta 側を設定する担当者に渡します(または、相手が求める 2 つの値を伝えます):
- ACS URL:
https://<your-server>/saml/acs - エンティティ ID:
https://<your-server>/saml
これらの URL は、ユーザーのブラウザーが到達するオリジンから導出されます。サーバーがトンネルやリバースプロキシの背後で動作している場合は、オリジンが安定していることを確認してください(設定 → サーバー → 接続とステータス → このサーバーを共有 に公開 URL が表示されます)— または、SPエンティティID フィールドでエンティティ ID を明示的に固定します。
4. ログインで何が付与されるかを選ぶ
「4. ログインで何が付与されるかを選ぶ」というセクション初回ログインの動作を決めるポリシーが 2 つあります:
- 初回ログイン時にユーザーを全ワークスペースに追加 — SSO が信頼と同義である単一チームのデプロイではオンのままにします。複数のチームや顧客がサーバーを共有する場合はオフにします。その場合、新規参加者にはワークスペースへの明示的な招待が必要になり、これがより安全な既定です。
- 初回ログイン時に未知のユーザーをプロビジョニング — 既定でオンです。アカウントがまだ存在しないユーザーを拒否するにはオフにします。
任意で、グループ名を運ぶ属性をマッピングし(Okta では一般に groups です)、マップでグループをロールに変換できます — 例えば {"platform-leads": "admin"} です。SSO がオーナーロールを付与することは決してありません。
5. 有効化してログインする
「5. 有効化してログインする」というセクションサインインにSAMLを使用をオンにし、接続を保存を押してから、プライベートブラウザーウィンドウで https://<your-server>/saml/login を開きます。Okta でサインインすると、Web クライアントに戻ります — ログイン済みで、アカウントが作成され、選んだポリシーに従ってメンバーシップが付与されています。
サーバーアドレスを入力した瞬間に、同じエントリーポイントが Web の接続画面に表示されます(SAMLでサインイン)。フォームはサーバーが提供する内容に適応します(OpenID Connect の場合は OpenID Connectでサインイン と表示されます)。このボタンは新しいタブでサインインを開きます。往復が完了すると、待機していたタブが自動的にセッションを引き継ぎます。デスクトップのサーバーセットアップ画面も同じです。サーバー URL を入力すると SAMLでサインイン ボタンが表示され、それがブラウザーを開き、往復が完了するとアプリがログインします。
6. このページから確認する
「6. このページから確認する」というセクションSSO を展開する前に、またはログインが失敗したときに、ここで各部を確認してください。チェッカーは完全にあなたのブラウザー内で実行されます。このタブで貼り付けたメタデータを読み取り、サーバーと同じルールを適用します。サーバーアドレスを指定すると、そのサーバーに SAML サインインが有効かどうかも問い合わせます。
アプリの 接続をテストでは見えないものを検出します。期限切れが近い署名証明書、署名付きリクエストを要求する IdP、そしてテストサインインによる、IdP が Control Center を認識しているかどうかです。
Runs in your browserYour metadata is read in this tab and never uploaded. Add a server address and your browser also asks that server which sign-in methods it offers.
Test sign-in at your IdP
- Your IdP's sign-in page: it recognizes Control Center's entity ID. You can close the tab.
- An error at your IdP: it names what to fix, usually an unknown entity ID (Entra: AADSTS700016) or a user not assigned to the app.
- Your server's "Sign-in failed" page: also a pass. The IdP accepted the request and posted back to your ACS URL; your server refuses it only because this page started the sign-in, not your server.
次のステップ
「次のステップ」というセクション- IdP にライフサイクル制御も任せる: SCIM でユーザーのプロビジョニングとプロビジョニング解除を行う。
- IdP が SAML ではなく OpenID Connect を使っていますか? OpenID Connect プロバイダーを接続。
- ブラウザーの往復が実際に何を検証するのか気になりますか? シングルサインオンの仕組み。