アイデンティティ・プロバイダの管理

アイデンティティ・ドメインと外部アイデンティティ・プロバイダ間のフェデレーテッド・ログインを設定できます。これにより、ユーザーは、アイデンティティ・プロバイダによって管理される既存のログインとパスワードを使用してOracle Cloud Infrastructureリソースにサインインおよびアクセスできます。

必要なポリシーまたはロール

アイデンティティ・ドメイン・セキュリティ設定およびアイデンティティ・プロバイダを管理するには、次のアクセス権付与のいずれかが必要です:

管理者グループのメンバーにします
アイデンティティ・ドメイン管理者ロールまたはセキュリティ管理者ロールを付与します
manage identity-domains権限が付与されているグループのメンバーにします

ポリシーおよびロールについてさらに理解するには、管理者グループ、ポリシーおよび管理者ロール、管理者ロールの理解およびIAMポリシーの概要を参照してください。

アイデンティティ・プロバイダおよびサービス・プロバイダについて

認証局とも呼ばれるアイデンティティ・プロバイダは、外部プロバイダの資格証明を使用してアイデンティティ・ドメインにサインインするユーザーに対して外部認証を提供します。アイデンティティ・ドメインは、サードパーティのサービス・プロバイダに対するアイデンティティ・プロバイダとして機能できますが、アイデンティティ・ドメインにアクセスするユーザーを認証するためにアイデンティティ・プロバイダに依存するというこのコンテキストでは、アイデンティティ・ドメインはサービス・プロバイダです。より一般的に、Oracle Cloud Infrastructureは、ユーザーがアクセスする必要があるサービスおよびリソースを提供するため、サービス・プロバイダと考えることもできます。

たとえば、Microsoft Active Directory Federation Services (AD FS)の資格証明を使用して組織のユーザーがOracle Cloudサービスにサインインおよびアクセスするとします。この場合、Microsoft AD FSはアイデンティティ・プロバイダ(IdP)として機能し、アイデンティティ・ドメインはサービス・プロバイダ(SP)として機能します。MS AD FSは、ユーザーを認証し、アイデンティティおよび認証情報を含むトークンをアイデンティティ・ドメインに返します(ユーザー名やユーザーの電子メール・アドレスなど)。このセキュリティ・トークンは、IdPによってデジタル署名されています。SPは、トークンの署名を検証してから、アイデンティティ情報を使用してユーザーの認証済セッションを確立します。これはフェデレーテッド・シングル・サインオンと呼ばれ、ユーザーはあるドメインで資格証明を要求され、別のドメインへのアクセス権を付与されます。

Microsoft Active Directoryブリッジをフェデレートするには、Microsoft Active Directory (AD)ブリッジの設定を参照してください。

デジタル証明書について

デジタル証明書は、電子パスポートのように、個人、コンピュータまたは組織が公開キー暗号化を使用してインターネット経由で情報をセキュアに交換するのを支援します。デジタル証明書は、公開キー証明書とも呼ばれます。

パスポートのように、デジタル証明書は、識別情報を提供し、改ざんに強く、正式な信頼できる機関によって発行されるため検証が可能です。証明書には、証明書保有者の名前、シリアル番号、有効期限、証明書保有者の公開キーのコピー(メッセージの暗号化およびデジタル署名の検証に使用)、および証明書発行機関(CA)のデジタル署名が含まれているため、受信者はその証明書が本物であることを確認できます。

外部アイデンティティ・プロバイダの署名を検証するために、サービス・プロバイダには署名証明書のコピーが格納されます。サービス・プロバイダがアイデンティティ・プロバイダから署名付きメッセージを受信する場合、格納された証明書を使用して署名を検証する前に、証明書が有効であることを検証する必要があります。証明書の検証には、証明書が期限切れになっていないかどうかの検証が含まれます。証明書が検証された後、その証明書を使用してメッセージの署名が検証されます。

この操作が成功するには、証明書に埋め込まれた公開キーが、アイデンティティ・プロバイダによってメッセージの署名に使用された秘密キーと一致している必要があります。

アイデンティティ・プロバイダの証明書が期限切れになるとどうなるか

アイデンティティ・プロバイダの署名証明書が期限切れになり、証明書の更新時に署名キー・ペアを変更すると、署名の検証が失敗し、アイデンティティ・ドメインはそのアイデンティティ・プロバイダのユーザーのシングル・サインオン(SSO)操作を完了できません。したがって、アイデンティティ・プロバイダの証明書がその有効期限に近づいたときに、それを置き換える計画を立てる必要があります。一般的なプロセスは次のとおりです:

アイデンティティ・プロバイダから新しい署名証明書を取得します。これは、セルフサービス・ダウンロード用にアイデンティティ・プロバイダによって公開されていることも、アイデンティティ・プロバイダ管理者への連絡が必要になることもあります。
新しい署名証明書をアイデンティティ・プロバイダのアイデンティティ・ドメイン構成にロードします。
アイデンティティ・プロバイダが(既存のキー・ペアに対して新しい証明書を再発行するのではなく)その署名秘密/公開キー・ペアもロールオーバーする場合、メッセージに署名するための新しいキーを使用できるように、アイデンティティ・プロバイダ構成を更新する必要があります。この場合も、セルフサービスを使用するか、アイデンティティ・プロバイダ管理者との調整が必要になります。

ノート

アイデンティティ・プロバイダが署名キー・ペアをロールオーバーすると、前述のステップ2からステップ3までの期間中にSSOが失敗します。このため、通常はアイデンティティ・プロバイダとアイデンティティ・ドメイン管理者の間で証明書の更新が調整されます。

SAMLジャストインタイム・プロビジョニングについて

SAMLジャストインタイム(JIT)プロビジョニングでは、ユーザーが最初にSSOを実行しようとしたときに、ユーザーがまだアイデンティティ・ドメインに存在しない場合、ユーザー・アカウントの作成が自動化されます。JITでは、自動ユーザー作成に加えて、プロビジョニングの一環としてグループ・メンバーシップの付与および取消しが可能です。JITは、サービス・プロバイダ(SP)ストア内のユーザーの属性をアイデンティティ・プロバイダ(IdP)のユーザー・ストア属性と同期できるように、プロビジョニングされたユーザーを更新するように構成できます。

利点

JITの利点は:

アイデンティティ・ドメイン内のユーザー・アカウントのフットプリントは、IdPのユーザー・ディレクトリ内のすべてのユーザーではなく、フェデレーテッドSSOを介して実際にサインインするユーザーに制限されます。
SSOプロセスの一環としてアカウントがオンデマンドで作成され、アイデンティティ・プロバイダとサービス・プロバイダのユーザー・ストアを手動で同期する必要がないため、管理コストが削減されます。
後でアイデンティティ・プロバイダ・ユーザー・ストアに追加された新規ユーザーは、対応するサービス・プロバイダ・アカウントを手動で作成する管理者を必要としません(ユーザーは常に同期されます)。

仕組み

JITプロビジョニングには4つのランタイム・フローがあります:


サインイン時のユーザー:	フロー
SPに存在し、JITプロビジョニングが有効になっています。	通常のSSOフロー。
SPに存在せず、JITプロビジョニングが有効になっていません。	通常のSSO失敗フロー。
SPに存在せず、JITユーザー作成が有効になっています。	ユーザーが作成され、JIT構成でのマップに従ってSAMLアサーション属性が移入されます。
SPに存在し、JIT更新が有効になっています。	ユーザー属性値が、JIT構成でのマップに従ってSAMLアサーション属性で更新されます。

Oracle Cloud Infrastructureドキュメント