Okta (OIDC) 設定

前提条件

• Okta管理者アカウント
• SecureCodingHub組織管理者アカウント

ステップ1 — Oktaアプリケーションを作成

ステップ2 — 認証情報をコピー

Oktaアプリケーションから次の値を収集してください:

ステップ3 — SecureCodingHubでSSOを構成

ステップ4 — テスト

Okta SAMLの一般的な落とし穴

このガイドはOIDCに焦点を当てていますが、多くのOktaテナントはSAML上でSecureCodingHubを実行しており、同じOkta固有の問題が再発します。1つ目はaudience URIの不一致です。OktaはこのフィールドをSAML General SettingsでAudience URI (SP Entity ID) と呼び、その値はSecureCodingHubがentity IDとして公開するものと正確に一致する必要があります。よくある間違いは、API entity IDではなくSecureCodingHub WebサイトURLを入力することです。Oktaアプリケーションを保存する前に、SecureCodingHub SSO設定ページのSP Entity IDフィールドに対して値を検証してください。

2つ目の落とし穴はOktaアプリのサインオンポリシーです。Oktaは、追加要素を要求したり、ネットワークゾーンで制限したり、グループメンバーシップに基づいてアクセスを完全に拒否したりできるアプリケーションレベルのポリシーを適用します。エンドユーザーがSSOによってOktaにリダイレクトされ、その後アクセス拒否エラーで跳ね返されることを報告した場合、原因はほぼ常にユーザーに一致しないアプリサインオンポリシールールです。アプリケーションの下のSign On Policyを確認し、テストユーザーに適用されるルールを確認してください。3つ目の一般的な落とし穴は不一致のName ID形式です。OktaはデフォルトでUnspecifiedですが、SecureCodingHubはemailAddress形式を期待しています。アプリケーション設定でName ID形式をEmailAddressに設定し、ソース属性がuser.emailまたはuser.loginであることを確認してください。

SSOがエンドツーエンドで動作することを確認する方法

検証は、以前のログインからのクッキーを避けるためにシークレットブラウザセッションから始まります。SecureCodingHubログインページに移動し、検証されたドメインの企業メールアドレスを入力し、ブラウザがOktaテナントにリダイレクトすることを確認します。Oktaで認証後、リダイレクトは正しい組織のダッシュボードでSecureCodingHubに着地するはずです。一般的なランディングページまたは404に着地した場合、最も可能性の高い原因は、ユーザーがまだSecureCodingHubに存在せず、JITプロビジョニングが無効か作成イベントを拒否したことです。

第2に、ロールとシートの割り当てを検証します。JITプロビジョニングされたユーザーは常にlearnerロールで着地します — SecureCodingHubは今日、Oktaグループクレームからロール情報を読み取らないため、org_adminへの昇格は、ユーザーが存在した後にSecureCodingHub管理UIから行う必要があります。第3に、サインアウトしてから、サインインし直します。2回目のログインは、Oktaセッションクッキーのおかげでほぼ静かであるはずです。2回目のログインが完全な再認証を強制する場合、Oktaセッションのライフタイムは通常の使用には短すぎる設定です。グローバルセッションポリシーまたはアプリケーションサインオンポリシーを適宜調整してください。プロトコルレベルの詳細については、SAMLセットアップガイドを参照してください。