Azure AD (OIDC) 設定
OpenID Connectを使用してMicrosoft Entra ID (Azure AD) でシングルサインオンを構成するステップバイステップガイド。
前提条件
- 管理者アクセスを持つAzure ADテナント
- SecureCodingHub組織管理者アカウント
- SecureCodingHubで検証された組織ドメイン
ステップ1 — Azure ADでアプリケーションを登録
Azure Portal → Microsoft Entra ID → App registrations → New registrationに移動
名前: SecureCodingHub SSO
サポートされるアカウントタイプ: この組織ディレクトリ内のアカウントのみ
リダイレクトURI: Web → https://api.limeplate.com/api/sch/auth/sso/callback/oidc
登録をクリック
ステップ2 — クライアントシークレットを作成
Certificates & secrets → New client secretに移動
説明: SecureCodingHub
有効期限: ポリシーを選択 (推奨: 24か月)
シークレット値をすぐにコピー — 一度だけ表示されます
ステップ3 — IDをメモ
Azure ADアプリケーションから次の値を収集してください。次のステップで必要になります。
| 設定 | 場所 |
|---|---|
| Application (Client) ID | Overviewページ |
| Directory (Tenant) ID | Overviewページ |
| クライアントシークレット | Certificates & secrets |
| ディスカバリURL | https://login.microsoftonline.com/{tenant-id}/v2.0/.well-known/openid-configuration |
ステップ4 — SecureCodingHubでSSOを構成
組織管理者としてログイン → SSO設定
プロトコル: OIDC
Entity ID / Client ID: Application IDを貼り付け
ディスカバリ / メタデータURL: OpenID構成URLを貼り付け
クライアントシークレット: シークレットを貼り付け
SSOを有効化
保存をクリック
ステップ5 — テスト
シークレット / プライベートブラウザウィンドウを開く
SecureCodingHubログインに移動
組織のドメインを持つメールアドレスを入力
Microsoftログインにリダイレクトされるはず
認証後、SecureCodingHubにログインしているはず
Azure AD SAMLの一般的な落とし穴
OIDCの代わりにAzure ADでSAMLを使用する場合、3つの失敗モードがほとんどのプロダクションインシデントの原因となります。1つ目は不一致のentity IDです。Azure ADはSSOブレードのIdentifierフィールドに任意の文字列を受け入れますが、SecureCodingHubで構成されたSP Entity IDと正確に一致しない場合、SAMLレスポンスはオーディエンス制限エラーで拒否されます。SecureCodingHub SSO設定ページから識別子を直接コピーし、入力しないでください。末尾のスラッシュとプロトコルの不一致 (httpとhttps) は一般的な静かな失敗です。
2つ目の落とし穴は、claim issuer URIの不一致です。Azure ADは公開するフェデレーションメタデータURLでアサーションに署名し、SecureCodingHubはSAMLレスポンスのissuerがメタデータのissuerと一致することを検証します。テナントを交換したり、証明書を再生成したり、別のアプリケーションからメタデータURLをコピーすると、issuerが分岐し、すべてのログインが無効な署名エラーで失敗します。3つ目の落とし穴は、グループクレームのサイズです。Azure ADは、アサーションが最大ペイロードを超えるとグループクレームを切り捨て、グループをグラフエンドポイント参照に置き換えます。下流のロールマッピングにグループクレームに依存している場合は、Azure ADを構成して、ユーザーが所属するすべてのグループではなく、アプリケーションに割り当てられたグループのみを発行してください。
SSOがエンドツーエンドで動作することを確認する方法
エンドツーエンド検証には3段階があります。第1に、シークレットウィンドウを開き、企業のメールアドレスを使用してSecureCodingHubログインページからログインを開始します。ブラウザはlogin.microsoftonline.comにリダイレクトし、Microsoftログイン体験を表示してから、SecureCodingHubにリダイレクトします。リダイレクト先が失敗した場合、失敗の瞬間のURLバーをキャプチャしてください。クエリ文字列のエラーコードは最も有用なエビデンスです。
第2に、ユーザーが正しい組織とダッシュボードに着地することを確認します。空のホームページまたは間違った組織へのリダイレクトでの成功したログインは、通常欠落した組織-ドメインマッピングを指します。第3に、サインアウトし、再度サインインし、2回目のログインが静かまたはほぼ静かであることを確認します。Microsoftセッションクッキーは2回目のフローをほぼ見えなくするはずです。両方のログインに完全な再認証が必要な場合、IdPアプリケーションはシングルサインオンクッキーの再利用を防ぐセッションポリシーを使用しています。共有トラブルシューティング手順については、SAMLセットアップガイドを参照してください。