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

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

外部 ID プロバイダー (IdP) を統合し、ご使用の IBM Cloud® アカウントに対して外部ユーザーをセキュアに認証できます。 IdP を使用すると、お客様の社内ユーザーがシングル・サインオン (SSO) を使用できるようになります。 選択した IBM Cloud App ID インスタンスとクラウド・アカウントを結び付けることにより、そのすべてを実現できます。

すべての IBM Cloud 製品を連携し、利用料金がかからない IBM の認証方式として広く利用されているのは、会社のドメインの登録による IBMid 連携です。 会社のドメインを IBM に登録すると、会社の既存のユーザー資格情報で IBM の製品やサービスにログインできるようになります。 その後、認証は、お客様の会社の IdP によってシングル・サインオン (SSO) を使用して処理されます。 フェデレーテッドIDへの貴社の登録方法については 、 IBMid のエンタープライズ・フェデレーション導入ガイドをご覧ください。 フェデレーテッドIDの登録を依頼する際には、 IBM スポンサー（製品アドボケイトやクライアントアドボケイトなど）が必要です。

設定を開始するにはIBMidエンタープライズフェデレーションについては、ibm.com/mysupport選択してIBMid製品としての Enterprise Federation。

IAM を介して外部 IdP 参照を使用する場合、各アカウントには、コンソールの「アクセス (IAM)」セクションにある「ID プロバイダー」ページで最大 5 つの IdP を追加できます。 IdP 参照は、IAM と統合する App ID インスタンスを選択してセットアップします。 その後、IdP 参照にはランダムなレルム ID が付与されます。この ID は、その App ID サービス・インスタンスのユーザーの固有の接頭部です。

ご使用の IdP で既に構成されている App ID インスタンスと IBM Cloud アカウントの間の統合をセットアップすることにより、その IdP のすべてのユーザーを外部から引き続き管理できるようになります。 また、エンタープライズ内のユーザーのクラウド・アカウントへのログイン・プロセスも簡単になります。 統合の完了後、ユーザーに対して、毎回のログイン時に使用するカスタム URL を提供する必要があります。 アカウントにユーザーを招待する必要はありません。接続した IdP のユーザー・リポジトリーにユーザーとして既に存在している場合には、カスタム URL 経由で資格情報を使用してログインできるためです。

開始前に

  • お客様に最適なフェデレーションオプションを決定するには 、 IBM Cloud のSAMLフェデレーションガイドをご確認ください。
  • App ID のインスタンスを IBM Cloud カタログから作成します。 詳しくは、『入門チュートリアル』を参照してください。
  • App ID インスタンスを構成します。 ユース・ケースに応じたその方法について詳しくは、認証の管理に関する App ID の資料を参照してください。
  • アカウント所有者ではない場合には、IdP 参照を表示および管理するために必要なアクセス権限があることを確認します。 App ID インスタンスにおけるオペレーター役割以上の役割、または IAM Identity サービスにおけるオペレーター役割または管理役割が割り当てられている必要があります。

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

ID プロバイダーの有効化と接続

アカウントで以前に IAM IdP を構成したことがない場合、最初にアカウントのログイン設定を有効にする必要があります。

  1. アカウントのログイン設定を有効にします。 既にこの設定を有効にしている場合には、この手順はスキップできます。

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

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

  2. **「作成」**をクリックして、IdP 参照を作成します。

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

  4. ユーザーのオンボード方法を選択してください

    • 静的 ：（デフォルト）各ユーザーが初めてログインした際に、そのユーザーをアカウントに追加する。
    • 動的 ：信頼済みプロファイルを選択しないでログインした場合のみ、ユーザーをアカウントに追加する。
    • なし: ユーザーはアカウントに追加されませんが、信頼できるプロファイルを使用してアカウントにアクセスできます。 トラステッド・プロファイルについて詳しくは、 トラステッド・プロファイルの作成 を参照してください。

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

  5. 次に、以下の設定を選択します (オプション)。

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

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

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

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

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

ただし、デフォルトとして設定できるのは 1 つだけですが、アカウントで最大 5 つのセットアップを設定できるため、別の IdP 参照用の URL を取得する必要がある場合があります。

  1. 「ID プロバイダー」ページで、URL が必要な IdP 参照の行のアクション・アイコンアクションのリスト・アイコンをクリックします。
  2. **「IdP URL の表示」**を選択します。
  3. **「IdP URL」**リンクをコピーし、ログインするユーザーに提供します。

App ID インスタンスによるアクセス・グループにおける動的ルールの作成

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

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

  • ID プロバイダー: IAM IdP の接頭部 appid:// とレルム ID を使用します。 例えば、ユーザーのレルム ID が appid://A1B2C3D4 であった場合には A1B2C3D4 です。
  • ユーザーを追加する条件: 他の SAML アサーションの名前を使用します。 このプロパティーは、未変更のまま渡されます。
  • Cloud Directory オプションまたは SAML フェデレーション・オプションを App ID で使用している場合には、各ユーザーのプロファイルにカスタム属性を追加できます。 それらのプロパティーも動的ルールに使用できます。 ただし、カスタム属性と SAML アサーションに同じプロパティーが含まれている場合、SAML アサーションのカスタム属性が使用されます。

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

外部の IdP, と連携している場合は、外部の IdP は1つだけに絞り、ユーザーは IdP を通じて自動的にオンボードするようにすることをお勧めします。

IBM Cloud 招待プロセスは IBMid のユーザーでのみ機能するので、この招待プロセスを使用してユーザーを招待しないでください。 アカウントで IBM Cloud 招待を使用した場合、IBMid からのユーザーと、外部 IdP から自動的にオンボードされたユーザーが混じってしまうことになります。 これにより、混乱状態が生じやすくなります。IBMid ユーザーは IBM Cloud Web サイト経由でログインし、外部 IdP からのユーザーは特別な URL を使用してログインする必要があるためです。 これは、1つのアカウントでユーザー名が重複する原因となり、前述のとおり、 Kubernetes Service の制限により推奨されません。

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

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

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

作成した条件により、企業ユーザー・ディレクトリーでフェデレーテッド・ユーザーに割り当てられている属性に応じて、フェデレーテッド・ユーザーがトラステッド・プロファイルの適用対象として除外または許可されます。 トラステッド・プロファイルを作成するときに、IdP データを表示して、組織の企業ユーザー・ディレクトリーにある自分のユーザー・クレームを確認することができます。

例えば、会社内の部門やチーム、さらに細かい内部組織を表す groups という名前の属性があるとします。 もし、同じプロジェクトで同じレベルのアクセス権限を必要とする開発者が米国の財務チームに所属している場合は、次の条件で信頼されたプロファイルを作成することができます

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

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

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

狭い条件を作成することをお勧めします。 組織の全員で同じ IdP URL を共有するので、クレーム・ルールが広すぎると、意図しないユーザーに、アカウントに対するアクセス権限を含むトラステッド・プロファイルが適用される可能性があります。