SAML IDプロバイダーの追加
SAML IDプロバイダー（IdP）の追加は、インバウンドSAMLの構成における最初のステップです。
このタスクを開始する
-
Admin Consoleで、に移動します。
-
［Add Identity Provider（IDプロバイダーを追加）］をクリックして、［Add SAML 2.0 IdP（SAML 2.0 IdPを追加）］を選択します。
-
［General Settings（一般設定）］を構成します。［View Setup Instructions（設定手順を表示）］のリンクが表示されたら、まずこれをクリックします。一部のプロバイダーには独自の詳細な手順があります。
［Name（名前）］ このIdPに付ける名前。 ［Protocol（プロトコル）］ SAML 2.0のみがサポートされています。 -
［Authentication Settings（認証の設定）］を構成します。
［IdP Username（IdPユーザー名）］ ユーザー名を含むSAMLアサーションのエンティティー。ドロップダウンリストには、デフォルト値saml.subjectNameIdが含まれます。 式を入力して値を再フォーマットできます。たとえば、SAMLアサーションのユーザー名がjohn.doe@mycompany.okta.comの場合、mycompany.oktaをendpointA.mycompanyに置き換えるように指定することで、ユーザー名をjohn.doe@endpointA.mycompany.comに変換できます。式を入力する場合は、Okta Expression Languageの構文を使用します。
［Filter（フィルター）］ ユーザー名フィルターとして式を入力する場合のみ、［Filter（フィルター）］を選択します。フィルターを指定すると、認証前のユーザー名の選択が制限されます。 ［Match against（照合対象）］ 変換されたユーザー名が認証されるOktaのフィールドを選択します。 ［Account Link Policy（アカウントリンクポリシー）］ OktaがユーザーのIdPアカウントを一致するOktaアカウントと自動的にリンクするかどうかを指定します。
セキュリティ強化のため、アカウントリンクは可能な限り無効にします。アカウントリンクが必要な場合、「セキュリティのベストプラクティス」に従ってください。
［Auto-link Restrictions（自動リンクの制限）］ 自動アカウントリンクが有効化されている場合は、リンクを指定されたユーザーグループに制限するかを指定します。 ［If no match is found（一致が見つからない場合）］ Just In Time（JIT）プロビジョニングで新しいユーザーアカウントを作成するか、エンドユーザーをOktaサインインページにリダイレクトするかを指定します。 1番目のオプションの場合、JITプロビジョニングを次の2つの場所で有効にする必要があります。
このページで、［Create new user (JIT)（新しいユーザーを作成（JIT））］をクリックします。
で、［Enable Just In Time Provisioning（Just In Timeプロビジョニングを有効化）］をクリックします。
-
［JIT Settings（JIT設定）］を構成します。
［Profile Source（プロファイルソース）］ このボックスを選択すると、このSAMLアサーションの情報で既存のユーザーが更新されます。このボックスが選択されない場合、プロファイル情報はプッシュされません。 ［Reactivation Settings（再アクティベーションの設定）］ このオプションは、［Update attributes for existing users（既存のユーザーの属性を更新）］が選択された場合のみ表示されます。 •［Reactivate users who are deactivated in Okta（非アクティブ化されているOktaユーザーを再アクティブ化）］：管理者は、非アクティブ化されたOktaユーザーをアプリで再アクティブ化したときに再アクティブ化するかどうかを選択できます。
•［Unsuspend users who are suspended in Okt（Oktaで一時停止されたユーザーの一時停止を解除）］：アプリで再アクティブ化したときに一時停止中のOktaユーザーの一時停止を解除するかどうかを管理者が選択できるようにします。
［Group Assignments（グループの割り当て）］ SAMLアサーションのユーザーを追加するグループを指定します。ドロップダウンメニューからいずれかのオプションを選択します。要求される情報はオプションごとに異なります。 ［None（なし）］：認証済みのユーザーをグループに追加しないでください。その他の情報は不要です。
［Assign to specific groups（特定のグループに割り当てる）］：［Specific Groups（特定のグループ）］フィールドにリストされたグループに各ユーザーを割り当てます。フィールドには1つ以上のグループを入力する必要があります。
［Add user to missing groups（見つからないグループにユーザーを追加）］：ユーザーは、SAMLアサーション内のまだメンバーではないグループに追加されます（ユーザーは、すでにメンバーとなっているグループのいずれからも削除されません）。［SAML Attribute Name（SAML属性名）］フィールドに、グループメンバーシップを表す値を持つSAML属性の名前を（SAMLアサーションの属性ステートメントで）入力します。これらの値は［Group Filter（グループフィルター）］フィールドで指定されたグループと比較され、一致する値によって、JITでユーザーが割り当てられるグループが決定されます。［Group Filter（グループフィルター）］フィールドは、セキュリティ許可リストとして機能します。IdPでユーザーに動的に割り当てるグループを一覧表示します。これにより、特定のグループに割り当てるユーザーを制御できます。［SAML Attribute Name（SAML属性名）］を入力して、［Group Filter（グループフィルター）］フィールドに1つ以上のOktaグループをリストする必要があります。
［Full sync of groups（グループの完全同期）］：このオプションは、［SAML Attribute Name（SAML属性名）］で指定された属性で表されるグループにユーザーを割り当てます（そのグループが［Group Filter（グループフィルター）］にリストされている場合）。
ユーザーが［SAML Attribute Name（SAML属性名）］フィールドの属性によって表される値と一致しないOktaグループのメンバーである場合、そのユーザーはOktaグループから削除されます。
-
［SAML Protocol Settings（SAMLプロトコルの設定）］を構成します。
［IdP Issuer URI（IdP発行者URI）］ IdPからの発行者URI。 ［IdP Single Sign-On URL（IdPシングルサインオンURL）］ IdPからのサインオンURL。［Request Signature（要求の署名）］オプションを選択してauthNリクエストに署名しているが、［Destination（宛先）］フィールドに宛先を指定していない場合（「高度な設定」を参照）、Oktaは自動的にauthNリクエストをIdPシングルサインオンURLに送信します。 ［IdP Signature Certificate（IdP署名証明書）］ アサーションの署名に使用されるIdPからの証明書。 -
任意。［Advanced Settings（高度な設定）］を構成します。
［Request Binding（要求のバインディング）］ SAML AuthNRequestメッセージをIdPに送信するためにOktaが使用するSAML認証要求プロトコルのバインディング。通常はHTTP POSTです。 ［Request Signature（要求の署名）］ Oktaから送信されるSAML AuthnRequestメッセージに署名するかどうかを指定します。このオプションを選択してauthN要求に署名すると、Oktaは自動的に［IdP Single Sign-On URL（IdPシングルサインオンURL）］フィールドに指定されたURLにauthN要求を送信します。 ［Request Signature Algorithm（リクエストの署名アルゴリズム）］ IdPに送信されるSAML authNメッセージの署名に使用される署名アルゴリズムを指定します。 ［Response Signature Verification（応答の署名検証）］ 受信応答を検証するときにOktaが受け入れる応答の署名のタイプを、［Response（応答）］、［Assertion（アサーション）］、あるいは［Response or Assertion（応答またはアサーション）］のいずれかで指定します。 ［Response Signature Algorithm（レスポンスの署名アルゴリズム）］ IdPによって発行されたSAMLメッセージおよびアサーションを検証するときの最小署名アルゴリズムを、［SHA-1］または［SHA-256］のいずれかで指定します。 ［Destination（宛先）］ SAML authN要求で送信される宛先属性。宛先を入力せず、［Request Signature（要求の署名）］オプションを選択してauthNリクエストに署名する場合、OktaはIdP Single Sign-On URLフィールド（SSO URL）で指定されたURLとして自動的に宛先属性を送信します。 ［Okta Assertion Consumer Service URL（OktaアサーションコンシューマーサービスURL）］ 信頼固有のAssertion Consumer Service（ACS）URLを使用するか、organization全体で共有されたURLを使用するかを指定します。 ［Max Clock Skew（最大クロックスキュー）］ アサーションの有効期間を指定します。数値を入力し、単位を選択します。認証プロセスで現在時刻とアサーションのタイムスタンプの時刻との差を計算して、その差が［Max Clock Skew（最大クロックスキュー）］の値を超えていないことを確認します。 -
［Add Identity Provider（IDプロバイダーを追加）］をクリックします。
Oktaメタデータの送信
IdPを作成したら、［Download metadata（メタデータをダウンロード）］をクリックしてこのプロバイダーのOkta SAMLメタデータにアクセスします。IdPの指示に従ってメタデータを提供します。
セキュリティのベストプラクティス
アカウントリンクを有効にする場合、次のベストプラクティスを検討してください。
IdPの構成
次の設定を使用します。
-
［Group Assignment（グループの割り当て）］：外部IdPにそれぞれ作成済みのグループを指定します。
-
［If no match is found（一致が見つからない場合）］：［Create new user (JIT)（新しいユーザーを作成（JIT））］を選択して、Okta orgにユーザーをプロビジョニングします。
-
［Account Link Policy（アカウントリンクポリシー）：外部IdPで作成された既存ユーザー全員がOkta orgにサインインを済ませた後に、アカウントリンクを無効にすることを検討します。この時点で、すべてのリンクが作成済みの状態です。リンクを無効にすると、外部IdPで作成された新しいユーザーはJITプロビジョニングによってOktaに追加されます。
-
［Filter（フィルタ）］：［Only allow usernames that match defined RegEx Pattern（定義された正規表現パターンに一致するユーザー名のみを許可）］を選択します。
-
外部IdPで作成されたユーザーが、Okta orgで作成されたユーザーとは異なるユーザー名ドメインを所有している場合、次のような正規表現パターンを使用します：^[A-Za-z0-9._%+-]+@spokedomain\.com
-
すべてのユーザーが同じドメインを共有している場合、特定のユーザーを除外する正規表現パターンを使用します。リストには、Okta orgの既知の管理者がすべて含まれている必要があります。明示的に指定したユーザー以外のすべてのユーザーに許可するには、次の式を使用します：^((?!(admin\.user\.1@company\.com|admin\.user\.2@othercompany\.com)).)*$
この式の定義によって許可されたユーザーが、特権アカウントです。
式は動的に更新されません。Okta orgで新しい管理者または特権ユーザーが作成された場合、式を手動で更新する必要があります。
-
認証ポリシー
-
Okta管理者が外部IdPからのフェデレーションを通じて親orgにサインインできないようにします。グローバルセッションポリシーを作成して、外部IdPで連携したユーザーである場合に、Okta管理者グループでアクセスを拒否します。IdPは複数選択が可能です。このポリシーが最初に評価されるように設定します。
-
外部IdPからのフェデレーションを通じてサインインしたすべてのユーザーが、管理者用ダッシュボードにアクセスできないようにします。それぞれの外部IdPに対する認証ポリシーを作成します。管理者用ダッシュボードなど、選択したアプリへのアクセスを拒否するようポリシーを構成します。機密性の高い任意のアプリに対するアクセスを制限できます。
-
可能な限り、すべてのOkta管理者にフィッシング耐性のあるオーセンティケーターを使用するように要求します。Okta管理者グループに対して多要素認証（MFA）を要求するようにグローバルセッションポリシーを作成します。
カスタム管理者ロールのあるユーザーは、Okta管理者と見なされます。そのためカスタム管理者ロールのあるユーザーは、Okta管理者を対象とするポリシーに含まれます。
フィッシング耐性のあるオーセンティケーターを要求する認証ポリシールールを構成します。
モニタリング
IdP経由の認証イベントをレビューするには、System Logを使用します。
eventType eq "user.authentication.auth_via_IDP"を見つけ、Okta System (SystemPrincipal)アクターとend userターゲットのあるイベントをレビューします。このようなイベントはアカウントリンク操作が発生したことを示します。ターゲットユーザーが特権ユーザー（または管理者）の場合、潜在的なインシデントへの対処がすべて為されていることを確認します。