SSO概要
SecureCodingHubは、OpenID Connect (OIDC) およびSAML 2.0を介したシングルサインオンをサポートします。SSOにより、チームは企業のIDプロバイダーでサインインできます — 別のパスワードは不要です。
サポートされるプロトコル
SecureCodingHubは、2つの業界標準のSSOプロトコルをサポートします:
OIDC (OpenID Connect)
OAuth 2.0ベースのモダンプロトコル。Azure AD、Okta、ほとんどのクラウドIDプロバイダーに推奨。PKCEを使用した認可コードフローを使用。
SAML 2.0
XMLベースのフェデレーションプロトコル。レガシーIDプロバイダーおよびエンタープライズ環境でサポート。
SSOの仕組み
組織でSSOが構成されている場合、ログインフローは次のように機能します:
ユーザーがSecureCodingHubログインに移動
組織のSSOエントリポイントに着地 (リンクには組織スラッグが含まれます。現在自動メールドメイン検出はありません)
ブラウザがIDプロバイダー (Azure AD、Oktaなど) にリダイレクト
ユーザーが企業認証情報で認証
IdPが認証トークンとともにSecureCodingHubにリダイレクト
SecureCodingHubがセッションを作成しユーザーをログイン
JITプロビジョニング
SSOが有効な場合、ユーザーは初回ログイン時に自動的に作成されます — これはJust-In-Time (JIT) プロビジョニングと呼ばれます。新しいユーザーはデフォルトで学習者ロールが割り当てられます。新しいユーザーをプロビジョニングするには、組織に利用可能なシートが必要です。
構成URL
IDプロバイダーを構成するときに次のURLを使用してください:
| 設定 | 値 |
|---|---|
| OIDCコールバックURL | https://api.limeplate.com/api/sch/auth/sso/callback/oidc |
| SAML ACS URL | https://api.limeplate.com/api/sch/auth/sso/callback/saml |
| SPメタデータURL | https://api.limeplate.com/api/sch/auth/sso/metadata |
SAMLとOIDCの選択
IDプロバイダーが両方のプロトコルをサポートしている場合、実用的な答えは、セキュリティチームが既に運用し信頼しているものを選択することです。OIDCは、OAuth 2.0上に構築されたより新しいJSONベースのプロトコルです。開発しやすく、デバッグしやすく、Azure ADやOktaを含むほとんどの最新IdPでのデフォルトオプションです。クラウドネイティブツールで標準化している組織にとって、通常OIDCが正しい選択です。
SAMLは古いXMLベースのフェデレーション標準で、エンタープライズ環境で最も一般的な選択肢として残っています。理由が技術的な選好であることはまれです。IdPチームが既に数十のSAML統合を運用しており、証明書ローテーションカレンダーが確立され、SAMLトラブルシューティングの社内プレイブックが成熟しているからです。PingFederate、ADFS、またはレガシーSAML IdPを持つ環境にデプロイしている場合、SAMLを選択すると、IdPチームにワンオフOIDC統合をサポートするよう依頼する代わりに、既存のパターンを再利用できます。どちらのプロトコルも同等のセキュリティを提供します。選択は暗号化ではなく運用上の適合に関するものです。
SSO前のチェックリスト
プロダクションでSSOを有効にする前に、3つの現実を計画してください。第1に、テスト環境をセットアップするか、エンドツーエンドで制御するテナントを使用します。誤って構成されたSSOは、構成した管理者を含む全員をロックアウトする可能性があります。最初に重要でない組織に対して完全なログインフローを実行します。理想的には使い捨てIdPアプリケーションで、緊急性なしに属性マッピングを繰り返せます。第2に、SSOに依存しない少なくとも1つのフォールバック管理者アカウントを保持します。SecureCodingHubはブレークグラスローカル管理者パスをサポートしており、それをテストする時はSSOが本番稼働する前であり、何かがうまくいかなかった金曜日の午後9時ではありません。
第3に、メールベースの招待フローへの下流の影響を考えてください。SSOがアクティブになると、検証されたドメインのユーザーはIdPにリダイレクトされ、初回ログイン時にJITプロビジョニングされます。これは、メールで手動でユーザーを招待する管理者と、IdPでアプリを割り当てるディレクトリ管理者の両方がアカウントを作成でき、1つを選ばないと2つのストリームが衝突することを意味します。よりクリーンなパターンは、SSO管理ドメインの手動招待を無効にし、IdPを唯一の信頼できる情報源にすることです。次のステップについてはSAMLセットアップガイドとプロトコル固有のガイドを参照してください。
SSO: よくある質問
SSOとは何の略で、どんな問題を解決しますか？
SSOはSingle Sign-On (シングルサインオン) の略です。ユーザーが企業のIDプロバイダーで一度サインインすると、認証情報を再入力することなく、SecureCodingHubを含む複数の下流アプリケーションにアクセスできる認証パターンです。要点は単なる利便性ではありません。セキュリティチームが、アプリケーションごとではなく1か所でパスワードポリシー、MFA、オフボーディングを強制できるようにします。
SSOとSAMLは同じものですか？
いいえ。SSOはユーザー向けのパターンで、SAMLはそれを実装できるプロトコルの1つです。SSO vs SAMLを比較するとき、よりクリーンなフレーミングは、SAML 2.0はIDプロバイダーからアプリケーションに認証アサーションを運ぶフェデレーション標準であり、SecureCodingHubはそれを話すということです。OIDC (OAuth 2.0上に構築) は、同じSSO結果のための最新の代替案です。
SSOとOAuthの実際の違いは何ですか？
OIDCがOAuth 2.0の上に存在するため、SSO vs OAuthの区別は人々を混乱させます。OAuth 2.0だけは認可フレームワークです — アプリケーションにリソースへのアクセスを付与します。OIDCはその上にID層を追加し、これがOAuthベースのSSOを可能にします。したがって、OAuth 2.0だけではSSOを得られませんが、OAuth 2.0上のOIDCはそれを提供します。
オープンソースIDプロバイダーでSSOを使用できますか？
はい。SecureCodingHubはオープン標準 — SAML 2.0およびOIDC — をサポートするため、それらを実装するすべてのオープンソースSSO IDプロバイダーが機能します。Keycloak、Authentik、Zitadelは、IdPをセルフホストしたいチームに一般的な選択肢です。SecureCodingHub側の構成手順はAzure ADまたはOktaと同じです。メタデータまたはディスカバリURLを提供し、属性をマップします。