外部 ID プロバイダーからの認証の有効化

外部 ID プロバイダー (IdP) を統合し、ご使用の IBM Cloud® アカウントに対して外部ユーザーをセキュアに認証できます。 IdP を使用すると、お客様の社内ユーザーがシングル・サインオン (SSO) を使用できるようになります。 IBM Cloud SAML サービス・プロバイダー（SP）、 App ID を使用するか、 IBMid を使用してユーザーをすべての IBM 製品にフェデレートすることで、クラウド・ アカウント外部の IdP に接続できます。

App ID および IBMid とのフェデレーションについては、 IBM Cloud SAML フェデレーション・ガイド を参照。

手動招待は IBMid のみを使用するため、フェデレートされたユーザーに対して IBM Cloud の招待を送信することは避けてください。 IBMid のユーザーと、外部 IdP から自動的にオンボー ドされるユーザーが混在すると、混乱を引き起こす可能性があります。

  • IBMid ユーザーは IBM Cloud ウェブサイトからログインする。
  • 外部の IdP ユーザーは、特別な URL でログインする必要がある。

この不一致はユーザー名の重複につながり、 Kubernetes Service で問題を引き起こす可能性がある。 よりスムーズな体験のために、ユーザーのオンボーディングには外部の IdP。

IBM Cloud Kubernetes Service リリース 1.18 以前では、アカウントで固有のユーザー名を使用します。 正しく動作させるには、すべてのユーザー名がすべての IdPs で一意であることを確認する必要があります。 IBMid からアカウントオンボー ドされたユーザー名と、IAM IdP からアカウントオンボー ドされたユーザーが重複しないようにしてください。 重複していると、IBM Cloud Kubernetes Service RBAC ルールは混乱し、不適切な許可が付与される場合があります。

IBM Cloud SAML サービスプロバイダー（SP）との連携

外部の IdP を IBM Cloud アカウント接続することで、企業内のユーザーのクラウド・ アカウントログイン・プロセスが簡素化されます。 統合の完了後、ユーザーに対して、毎回のログイン時に使用するカスタム URL を提供する必要があります。 あなたのアカウント誰かを招待する必要はありません。 接続されている IdP's のユーザーリポジトリにユーザーとして存在する場合、カスタム URL からその認証情報でログインすることができます。

ユーザーの認証に成功すると、そのユーザーは自動的にアカウント追加されます。 追加されたユーザーには、デフォルトではアクセス・ポリシーは割り当てられません。 しかし、アクセス・グループや信頼されたプロファイルに ダイナミック・ルールを 使用することで、ユーザーの主張に基づいて自動的に割り当てられるアクセス・ポリシーを設定することができます。

IBM Cloud SAML SP で ID プロバイダーを有効化し、接続する

アカウント IAM IdP 参照がない場合は、まずアカウントログイン設定を有効にする必要があります。

  1. アカウントのログイン設定を有効にします。

    1. IBM Cloud コンソールで管理 > アクセス (IAM) > ID プロバイダーに移動し、有効化をクリックします。
    2. アカウントにログインするためにユーザーに提供するデフォルトのアカウント URL の別名を入力します。

    外部ユーザーと URL を共有するので、エイリアスはユニークでシンプルなものにしてください。 一般によく使用される形式は、会社名やその変化形です。

  2. Addをクリックして、 IdP のリファレンスを追加します。

    1. を選択する。 IBM Cloud SAML SP

  3. SP 構成に名前を付けて、他の IdPs に接続するために作成する他の SP 構成と区別できるようにします。

  4. 詳細設定を確認し、必要に応じてデフォルトの選択を調整します。

    ほとんどの IdPs は署名付きアサーションをサポートしており、認証にはこれで十分である。 署名付きアサーションがすでに有効になっている場合、ユーザー ID などの重要なデータは保護されているため、完全なレスポンス署名は冗長になることが多い。 しかし、組織によっては、コンプライアンスやセキュリティ・ポリシーのために、メッセージのすべての部分が検証されていることを保証するために、完全なレスポンス署名を要求するところもある。

  5. SPコンフィギュレーションをダウンロードする。 次へ をクリックします。

  6. IdP にアクセスし、新しい SAML 2.0 アプリケーションを作成する。

  7. IBM Cloud SAML SP構成をアップロードし、 IdP メタデータをダウンロードする。

  8. IdP メタデータを IBM Cloud にアップロードする。

  9. 詳細設定を見直す。 IBM Cloud から署名付き SAML リクエストをリクエストする場合、 IBM Cloud は認証リクエストを IdP に送信する前に署名する。 次へ をクリックします。

  10. Verify をクリックして、 IBM Cloud SP と IdP との間の SAML 接続をテストする。

    1. ユーザー名やパスワードなど、 IdP の認証情報を入力してください。

  11. 接続結果を見る

    • 接続に失敗した場合は、 IdP のメタデータが正しく、 IBM Cloud が IdP に到達できることを確認してください。 SAML 接続の問題をトラブルシューティングするために、 IdP のログを確認してください。 IdP または SP 構成に必要な更新を行う。

      ログには、認証リクエストの詳細、 SAML レスポンス、メタデータの不一致や署名の検証に関するエラーなどが含まれる。

    • 接続に成功した場合は、［ 次へ］をクリックします。

  12. 必要な IAM クレームに自動的にマッピングされる IdP アサーションを確認する。 デフォルトのマッピングを上書きしたり、属性名が自動的に入力されない場合は、 IdP から手動で入力することができます。 詳細については、 IdP アサーションを IAM クレームにマッピングするを 参照。

    1. 必須でない属性の名前を IdP から変更する場合は、 マッピングの追加をクリックします。

  13. Next] をクリックし、[ Test ] をクリックしてアサーション・マッピングをテストします。

  14. 「完了 (Finish)」 をクリックします。

共有 IBM Cloud SAML IdP 構成

IBM Cloud SAML サービス・プロバイダーを設定し、外部 IdP, に接続した後、 IdP 設定を他のアカウント共有し、ログイン URL をユーザーに提供できる。 ユーザーは IdP を通して認証され、ログインに成功すると自動的にアカウント追加されます。

SAML IdP 構成を共有するには、以下の手順を実行します：

  1. IBM Cloud コンソールの Manage > Access (IAM) > Identity providers に進み、 Ready to use 状態の既存の IdP を選択するか、 IBM Cloud SAML SP で ID プロバイダを有効化および接続する の説明に従って新しい IdP を作成する。
  2. 他のアカウント IdP を共有するには、[ Shared with ]タブをクリックします。
  3. 追加 をクリックし、 アカウント のセクションで、 IdP を共有したいアカウント選択し、 シェア をクリックします。
  4. 外部 セクションで、 アカウント または エンタープライズ のいずれかを選択し、 アカウント ID を入力して 追加 をクリックする。 また、複数のアカウント IDを追加することもできます。
  5. 選択したアカウント IdP を共有するには、「 共有 」をクリックします。
  6. ユーザーが認証してアカウントアクセスできるように、ログイン URL。

SAML IdP

SAML IdP を他のアカウント共有した後、自分のアカウント IdP を消費できる。

  1. Add > Shared with you をクリックすると、あなたと共有されている IdPs が表示されます。
  2. 使用する IdP を選択し、 Nextをクリックします。
  3. アカウントログインを有効にする toggleを はい に設定し、 セーブ をクリックして、ユーザーがアカウントログインできるようにします。
  4. この IdP をアカウントログインのデフォルト IdP として設定するには、 「Set as default」 トグルを「 Yes 」に設定します。
  5. ユーザーが IdP からログインする際の管理方法に基づいて、 ユーザー管理からユーザーを選択します。
  6. 保存 をクリックします。

消費しない IdP

IdP, を使用する必要がなくなれば、それを消費しないことができる。 IdP をアンコンサムすると、 アカウント利用可能な IdPs のリストから IdP が削除され、 IdP に関連付けられているすべてのユーザーがアカウント削除されます。

  1. IBM Cloud コンソールの Manage > Access (IAM) > Identity providers に移動する。
  2. タイプが IBM Cloud SAML となっている IdP を選択する。
  3. アクションアイコン IdP, を含む行のアクションアイコン をクリックし、 削除をクリックします。

IdP ステータスを確認する

  1. IBM Cloud コンソールの Manage > Access (IAM) > Identity providers に進み、 Ready to use 状態の既存の IdP を選択するか、 IBM Cloud SAML SP で ID プロバイダを有効化および接続する の説明に従って新しい IdP を作成する。
  2. 詳細タブをクリックして、 IdP のステータスを表示する。
    • 非アクティブ: 非アクティブタグを持つ IdPs は、所有者によってグローバルに無効化される。 Actions > Enableをクリックして有効にする。
    • ログインに失敗します ： IdP はアクティブではありません。 行動 > 有効にする をクリックし、 アカウントログインを有効にする のトグルをオンにして有効にする。
    • すぐに使用できます ： IdP の設定は完了しているが、 アカウントログインはまだ有効になっていない。 アカウントログインに使用 のトグルをオンにして有効にする。

IdP アサーションを IAM クレームにマッピングする

IdP から IBM Cloud IAM ク レームに ID アサーションを手動でマッピングすることは任意である。 IBM Cloud は、認識された IdP アサーションのリストを、表 1 の必要な IAM クレームに自動的にマッピングする。 必要な SAML アサーション・マッピングが見つからず、属性マッピングも利用できない場合、 SAML テストは失敗する。 必須クレームが IdP アサーションに自動的にマッピングされない場合は、マッピングを定義するか、 IdP のアサーション名を更新して、期待される IAM クレームに一致させる。

あなたの IdP は、 region や department のように、 IBM Cloud が必要としない属性をさらに送るかもしれない。 IBM Cloud はこれらの追加属性を受け取り、属性ベースのアクセス制御（ABAC）に使用できるユーザークレームとして利用できるようにする。

IdP の設定に矛盾がない限り、ほとんどのユーザーはマッピングを作成する必要はない。 例えば、 IdP が email ではなく user_email を使っている場合。

IdP が以下の SAML アサーション・スキーマに一致しない場合のみ、属性マッピングを完了する：

IBM Cloud が認識する、必要な IAM クレームとそれに対応する IdP アサーションのリスト。
属性 ソース 説明
email (必須) SAML アサーション "email "からマップされる。 ユーザーの E メール・アドレス。 これは認証のための必須フィールドです。
ユーザー名 (必須) SAML アサーション "preferred_username"、"username"、"user_name"、または "userName" からマッピングされる。 利用可能なものがない場合は "subject "に戻る。 CLI、API、その他のプラットフォーム・サービスに表示される識別子。 電子メールであることが多いが、別のユニークな値であることもある。
名 (必須) SAML アサーション "given_name", "givenname", "givenName", "first_name", "firstname", または "firstName" からマッピングされる。 ログインするユーザーの名。
ラストネーム (必須) SAML アサーション "family_name", "familyname", "familyName", "last_name", "lastname", または "lastName" からマッピングされる。 ログインするユーザーの姓。
追加属性（オプション） IdP が提供するカスタム SAML アサーション。 これらの属性は、アクセスグループの動的ルールや、信頼されたプロファイルのフェデレーション・ユーザーの信頼関係で使用できる。

との連携 App ID

App ID を通して外部 IdP 参照を使用する場合、 アカウント、コンソールの「Access (IAM)」セクションの「Identity providers」ページから、最大 5 つの IdP 参照を追加できる。 IdP 参照は、IAM と統合する App ID インスタンスを選択してセットアップします。 そして、 IdP 参照は、その App ID サービスインスタンスのユーザーにとって一意な接頭辞であるランダムなレルム ID として与えられる。

IdP,、すでに設定されている App ID インスタンスとの統合を設定することで、 IdP ですべてのユーザーを外部で管理し続けることができます。 また、企業内のユーザーのアカウントログインプロセスを簡素化します。 統合の完了後、ユーザーに対して、毎回のログイン時に使用するカスタム URL を提供する必要があります。 あなたのアカウント誰かを招待する必要はありません。 接続されている IdP's のユーザーリポジトリにユーザーとして存在する場合、カスタム URL からその認証情報でログインすることができます。

まずは以下の条件をご確認ください：

  • App ID のインスタンスを IBM Cloud カタログから作成します。 詳しくは、『入門チュートリアル』を参照してください。
  • App ID インスタンスを構成します。 ユース・ケースに応じたその方法について詳しくは、認証の管理に関する App ID の資料を参照してください。
  • アカウント所有者でない場合は、 IdP 参照を表示および管理するために必要なアクセス権を持っていることを確認してください。 App ID インスタンスでは operator ロール以上、 インスタンスでは operator ロールまたは administration ロールが割り当てられていること。 IAM Identity Service.

IAM統合のための App ID インスタンスの設定

IBM Cloud アカウント IAM アイデンティティ・プロバイダー ( IdP ) として正しく動作するために、 App ID インスタンスをどのように構成する必要があるか、以下の要件を確認してください。

IAM IdP 統合用に App ID インスタンスを使用する予定の場合、その App ID インスタンスで認証できるあらゆるユーザーがアカウントにログインできます。 したがって、インスタンスを構成する際には、以下のガイドラインを考慮してください：

以下のタイプの認証を無効にします。

  • Facebook
  • Google
  • IBMid
  • 匿名

認証方法としてCloud Directoryを使用している場合は、ユーザーがアプリからサインアップするオプションを無効にし、代わりに既知のユーザーのみを個別に Cloud Directoryに 追加します。

App ID トークンにおける IAM 固有属性の設定

IAMを外部 IdP, で正しく動作させるには、 App ID インスタンスが必要な属性をすべて提供していることを確認する必要がある。 必要な属性については、以下の表を参照してください。

App ID トークンに必要な属性
属性 App ID ID トークン・クレーム ソース 説明
identifier (必須) ID App ID によって生成されます。 ユーザーを識別する固有 ID。 そのユーザーの存続期間中は変更できません。App ID がこの ID を作成します。
email (必須) email SAML アサーション "email" からマップされ、クラウド・ディレクトリーと SAML の構成で必須です。 ユーザーの E メール・アドレス。
username (推奨) 存在する場合には preferred_username。そうでない場合には sub。 使用可能な場合には、SAML アサーション "preferred_username"、"username"、"user_name"、または "userName" からマップされます。 そうでない場合には、App ID 生成の "sub" クレームが使用されます。 CLI、API、または IBM Cloud Kubernetes Service で作業する場合、ユーザー名が表示されます。 多くの場合、ユーザー名は E メール・アドレスですが、別の値にすることもできます。 App ID によってユーザー名が提供されない場合、IAM によって ID が代わりに使用されます。
firstname (推奨) 使用可能な場合には given_name。そうでない場合は、デフォルトとして "notset"。 使用可能な場合には、SAML アサーションの "given_name"、"givenname"、"givenName"、"first_name"、"firstname"、または "firstName" からマップされます。そうでない場合には、IAM によって定数 "notset" が使用されます。 ログインするユーザーの名。
lastname (推奨) 使用可能な場合には、family_name。そうでない場合は、デフォルトとして "notset"。 使用可能な場合には、SAML アサーションの "family_name"、"familyname"、"familyName"、"last_name"、"lastname"、または "lastName" からマップされます。そうでない場合には、IAM によって定数 "notset" が使用されます。 ログインするユーザーの姓。
name (オプション) 存在する場合は名前。そうでない場合には、名、スペース、および姓で構成されます。 からの自動マッピングはありません。 SAML 氏名。名と姓に含まれない、ミドルネームのイニシャル、肩書などを含みます。

App ID アカウントで IBM Cloud サービス・インスタンスを使用してユーザー認証が正常に実行されると、ユーザーはアカウントに自動的に追加されます。 追加されたユーザーには、デフォルトではアクセス・ポリシーは割り当てられません。 ただし、アクセス・グループと動的ルールを使用すると、割り当てられるアクセス・ポリシーを自動的にセットアップできます。

アイデンティティ・プロバイダを有効にし、接続する App ID

アカウント IAM IdP 参照がない場合は、まずアカウントログイン設定を有効にする必要があります。

  1. アカウントのログイン設定を有効にします。

    1. IBM Cloud コンソールで管理 > アクセス (IAM) > ID プロバイダーに移動し、有効化をクリックします。
    2. アカウントにログインするためにユーザーに提供するデフォルトのアカウント URL の別名を入力します。

    外部ユーザーと URL を共有するので、エイリアスはユニークでシンプルなものにしてください。 一般によく使用される形式は、会社名やその変化形です。

  2. Addをクリックして、 IdP のリファレンスを追加します。

    1. App ID を選択する。

  3. IdP 参照の名前を入力し、接続する App ID インスタンスを選択します。

  4. ユーザーの搭乗方法を選択します：

    • Static: (デフォルト) 初回ログイン時に各ユーザーをアカウント追加します。
    • ダイナミック ：ユーザーがログインし、信頼できるプロファイルを選択しなかった場合にのみ、 アカウントユーザーを追加します。
    • 決して ：ユーザーはアカウント追加されませんが、信頼されたプロファイルを使用してアカウントアクセスできます。 信頼済みプロファイルの詳細については、 信頼済みプロファイルの作成を 参照してください。

    オンボーディングを静的に設定し、初回ログイン時にユーザーが信頼できるプロファイルを選択したとします。 この場合でも、ユーザーはアカウント追加される。

  5. 次に、以下の設定を選択します（オプション）：

    • アカウント・ログインを有効にしますか?: ユーザーがアカウントにログインするために使用する IdP 参照を有効にします。 このオプションは、IdP 参照を初めて作成するときにデフォルトで設定されます。
    • デフォルトとして設定しますか?: ユーザーは、この機能を有効にしたときに作成したデフォルトの IdP 参照 URL を使用して、 アカウントログインできます。 デフォルトの IdP 参照は 1 つだけ設定できます。 作成するその他すべての IdP 参照については、レルム ID を使用してログインする必要があります。

  6. 「作成」 をクリックします。

この時点で対象 IdP 参照が ID プロバイダー・リストで使用可能になり、IBM Cloud の IAM IdP を表わす値としてレルム ID が自動的に生成されます。

との連携 IBMid

IBM Cloud でよく使われる認証方法で、 IBM の全製品でフェデレーションができ、利用料もかからないのが、 IBMid 会社のドメインを登録するフェデレーションです。 会社のドメインを IBM に登録すると、会社の既存のユーザー資格情報で IBM の製品やサービスにログインできるようになります。 御社の IdP、シングルサインオン（SSO）による認証を行います。 フェデレート ID の登録方法については、 IBMid Enterprise Federation Adoption Guide を参照してください。 フェデレーテッドIDの登録申請には、プロダクト・アドボケイトやクライアント・アドボケイトなど、 IBM スポンサーが必要です。

エンタープライズフェデレーション用に IBMid のセットアップを開始するには、 ibm.com/mysupport でケースを開き、製品として IBMid Enterprise Federation を選択します。

外部 ID プロバイダー資格情報によるログイン

App ID インスタンスを IdP に接続し、App ID インスタンスを IAM と統合すると、ユーザーはアカウントにログインできるようになります。 IdP 参照がデフォルトとして設定されている場合、アカウントの**「デフォルト IdP URL」**を共有できます。

  • デフォルトで設定できるのは1つだけですが、 アカウント最大5つまで設定できます。
  • リンクをコピーする。 IdP URLURL リンクをテーブルからコピーして、 IdP 参照の行に使用する。

IdP、アクセス・グループのダイナミック・ルールを構築するためにデータを使用する

必須属性に加えて、 SAML アサーションで任意のタイプの情報を渡すことができます。 これらの属性は、アクセス・グループの動的ルールで使用できます。

動的ルールを正常に作成するには、以下の情報が必要です。

ID プロバイダー
IBM Cloud SAML プロバイダーについては、 IdP に設定されているサービス・プロバイダーのエンティティIDを使用する。 App ID の場合は、接頭辞 appid:// と IAM IdP のレルム ID を使用する。 例えば、ユーザーのレルム ID が appid://A1B2C3D4 であった場合には A1B2C3D4 です。
ユーザーを追加する条件
追加 SAML アサーション名を使用する。 このプロパティーは、未変更のまま渡されます。

ダイナミック・ルールでもカスタム属性を使用できる。 ただし、カスタム属性と SAML アサーションに同じプロパティーが含まれている場合、SAML アサーションのカスタム属性が使用されます。

外部 IdP, で作業している場合は、1つの外部 IdP のみに接続し、この IdP を介してユーザーを自動的にオンボードさせます。

IdP データを使用したトラステッド・プロファイルの作成

IdP, を有効にして接続したら、 信頼済みプロファイルの作成を 開始できる。 フェデレーテッド・ユーザーとの信頼を構築するために、IdP の個人データを使用して、組織に存在する属性の名前と値を検索することができます。

トラステッド・プロファイルを作成する対象のユーザーが IBM Cloud App ID を使用する場合は、App ID ユーザーとしてトラステッド・プロファイルを作成します。IBMid についても同様です。 この方法により、独自の SAML 属性を使用して、トラステッド・プロファイル条件を構成する方法を理解することができます。 同じ IdP を持つ他のユーザーは、異なる SAML 属性を持つことができ、あなた自身の属性はヒントとしてのみ使用できます。 独自の属性とは異なる属性をクレームで使用するには、それらを手動で入力します。

作成した条件によって、連携ユーザーが信頼済みプロファイルを適用できないようにしたり、適用できるようにしたりできます。 アクセスは、企業のユーザー・ディレクトリで連携ユーザーがどの属性を割り当てられているかに依存します。 トラステッド・プロファイルを作成するときに、IdP データを表示して、組織の企業ユーザー・ディレクトリーにある自分のユーザー・クレームを確認することができます。

例えば、 groups と呼ばれる属性が、部署やチーム、さらに細かい社内組織を識別するとする。 米国にいる財務チームの開発者が、あるプロジェクトに多くのアクセスを必要とする場合、以下の条件で信頼されたプロファイルを作成することができる：

  • groups が finance-dev と等しい場合にユーザーを許可する
  • country が us と等しい場合にユーザーを許可する

意図したフェデレーテッド・ユーザーにのみアクセス権限が付与される条件にするために、使用可能な属性についての詳細を企業ディレクトリー・アーキテクトに問い合わせてください。

条件の作成に使用されるフィールドについて詳しくは、IAM 条件プロパティーを参照してください。

狭い条件を作り出す。 あなたは IdP URL を組織内の全員と共有している。 クレーム・ルールがオープンすぎると、ユーザーが意図せずにあなたのアカウントアクセスできる信頼済みプロファイルを適用してしまう可能性があります。