目次


ハイブリッド・クラウドに使用する認証方式を把握する

IBM Cloud Public、Dedicated、および Local 環境内のユーザーを管理する方法

Comments

IBM Cloud 内でのさまざまな選択肢には、ユーザー認証に関する多様な要件が伴います。この記事では、IBM Cloud ユーザーを管理および認証する際に選択できる各種の方法について説明します。専用クラウドまたはローカル・クラウドを使用している使用しているとしたら、この記事はまさにうってつけです。

IBM Cloud 環境のタイプ

さまざまな認証方式についての説明を読む前に、皆さんのアプリケーションには、どの環境が最適であるかを判断してください。IBM Cloud 内では、次の 3 つのデプロイメント方法を選択できます。

  1. IBM Cloud Public。Weather.com などのオファリングをはじめとする 130 を超える優れたサービスを利用して、数百万ものアプリケーション、コンテナー、サーバーなどを実行できます。開発したアプリケーションは、すぐに IBM Cloud 上で実行できます。
  2. IBM Cloud Dedicated。企業はデータ・センター内にハードウェアを物理的に隔離した状態で、専用のクラウド環境を利用できます。シングル・テナント型で、ベアメタルと仮想マシンの組み合わせを使用してプロビジョニングされるこの IBM Cloud 環境は、単一の顧客専用に作成されます。
  3. IBM Cloud Local。オンプレミスのサービスとして提供されます。IBM Cloud Local は PaaS (Platform as a Service) として利用できるだけでなく、基礎となる IaaS (Infrastructure as a Service) を運用することもできます。この組み合わせは、企業にフルスタックのクラウド・エクスペリエンスを可能にします。

IBM Cloud 内でのこれらの選択肢には、ユーザー認証に関する多様な要件が伴います。この記事では、IBM Cloud ユーザーを管理および認証する方法として考えられる、さまざまな可能性について説明します。

サポートされる認証方式

IBMid

利用できる環境: Public、Dedicated、Local

IBMid は、IBM のアプリケーション、サービス・トライアル、コミュニティー、サポート、オンライン購入などへのアクセスを提供します。IBMid はその所有者とプロパティーによって管理されます。管理に使用されるプロパティーにはプロファイル情報とパスワードが含まれ、どちらも IBM サーバー上に保管されます。パスワード管理 (パスワードの変更や、パスワードを忘れた場合の新しいパスワードの取得) は、IBM のページから行います。IBMid のパスワード・ポリシーには、このリンク先のページで説明されている特定の制約が適用されます。

また、IBMid には、IBM の顧客やパートナーが IBMid フェデレーションによって組織の SAML アイデンティティー・プロバイダーに IBMid 認証を統合する際のサポートも用意されています。このサポートにより、組織の SAML アイデンティティー・プロバイダーは IBM の Web アプリケーションとクラウド・サービスを利用しているユーザーのすべてを管理できるようになります。パスワードに関連するすべてのタスクと組織のユーザーの認証は、組織が処理します。企業は IBMid フェデレーションにより、独自のログイン・ページとセキュリティー・コントロールを使用して、IBM クラウド・アプリや IBM サービスへのアクセスをセキュリティーで保護することができます。

IBMid フェデレーションとその前提条件および導入プロセスについては、このリンク先の「IBMid Enterprise Federation Adoption Guide」を参照してください。

LDAP

利用できる環境: Public、Local

LDAP (Lightweight Directory Access Protocol) は、ディレクトリー内に保管されている情報にアクセスし、その情報を保守する際の業界標準のアプリケーション・プロトコルです。LDAP はオープンで、ベンダーに依存しないことから、幅広いベンダーがサポートしています。最も典型的な LDAP の使用法は、ユーザー名とパスワード、およびその他のプロファイル情報 (メール・アドレスなど) を 1 カ所に保管して一元管理するために使用するというものです。

図 1. 異なる複数のクライアントからのユーザーを認証・許可する LDAP サーバー
LDAP 認証を説明する図
LDAP 認証を説明する図

ディレクトリー・スキーマ

LDAP を使用してアクセスできるディレクトリー・サーバーには一般に、さまざまなタイプのエントリーが保管されます。以下のコードに示されている objectClass というタイプが、エントリーに必須の属性と任意に設定できる属性を定義します。ユーザー・エントリーには、値が person または inetOrgPerson に設定された objectClass が使用されます。1 つのエントリーに複数の objectClass ルールを適用して、エントリーを複数の objectClass に関連させることもできます。

リスト 1. ユーザーを表す LDAP エントリーの例
dn: CN=John.Doe,OU=users,OU=root
cn: John.Doe
objectclass: person
objectclass: inetOrgPerson
firstName: John
sn: Doe
mail: John.Doe@company.com
phone: +1 2345 67890
employeeType: permanent
...

グループ・エントリーの場合、objectClass の値には一般に group、groupOfNames、または groupOfUniqueNames が使用されます。リスト 1 に示されているように、1 つのエントリーに同時に複数の objectClass ルールを適用することもできます。

リスト 2. グループを表す LDAP エントリーの例
dn: CN=MyGroup,OU=groups,OU=root
cn: MyGroup
objectclass: groupOfNames
member: CN=John.Doe,OU=users,OU=root
member: CN=Jane.Doe,OU=users,OU=root
...

上記のリスト 2 に示されているサンプル・エントリーからわかるように、各エントリーには、そのエントリーをディレクトリー・サーバー内で一意に識別する識別名 (DN) があります。

LDAP による認証

LDAP とディレクトリー・サーバーを使用してユーザーを認証するには、一般に以下の 3 つの手段が使用されます。

  • 検索と比較: クライアント・アプリケーションがユーザーのエントリーを検索し、そのユーザーのパスワードを、ディレクトリー・サーバー内に保管されているパスワードと比較します。ディレクトリー・サーバーはパスワードの保管方法に関してさまざまなアルゴリズムを使用する可能性があるため、クライアントは多数のアルゴリズムをサポートできるようでなければなりません。.
  • シンプル・バインド: まず、ユーザーの DN が生成ルール (dn=cn=${username},ou=users,ou=root) に従って作成されます。例えば、ユーザーが「Richard Roe」だとすると、このユーザーの DN は dn=cn=Richard.Roe,ou=users,ou=root となります。次のステップでは、DN とユーザーのパスワードを使用して LDAP バインド (LDAP を使用して認証するための関連付け) が作成されます。
    リスト 3. ldapwhoami を使用したログイン資格情報の検証
    ldapwhoami -H “ldaps://myserver.com” 
               -D “CN=Richard.Roe,OU=users,OU=root” 
               -w “***”
  • 検索とバインド: LDAP を介して情報ツリーまたはサブツリーを検索します。通常、この検索には名、姓、またはメール・アドレスなどの条件が使用されます。検索結果としてユーザーの DN が取得され、シンプル・バインドと同じようにその DN とユーザーのパスワードを使用して LDAP バインドが作成されます。以下に示す例では、Richard Roe の e-メール・アドレスを使用してこのユーザーの DN を検索した後、LDAP バインド処理を使用してユーザーのパスワードを検証しています。
    リスト 4. ldapsearchldapwhoami を使用した検証
    ldapsearch -H “ldaps://myserver.com” 
                    -b "OU=users,OU=root" -x 
                    "(&(objectClass=person)(mail=Richard.Roe@company.com))" dn
    
    ...
    dn: CN=Richard.Roe,OU=users,OU=root
    ...
    ldapwhoami -H “ldaps://myserver.com” 
                    -D “CN=Richard.Roe,OU=users,OU=root” 
                    -w “***”

IBM Cloud Dedicated 環境では、顧客が所有する LDAP ディレクトリー・サーバーに接続するために、顧客環境への VPN トンネルを確立しなければならないことがよくあります。通常、IBM Cloud Dedicated から LDAP ディレクトリー・サーバーに直接アクセスすることはできません。

ユーザー管理

LDAP ディレクトリー・サーバーには、名、姓、メール・アドレス、ユーザー名などの情報が保管されます。さらに、LDAP ディレクトリー・サーバーに顧客の組織的構造を表すグループが保管されていることも珍しくありません。その場合、グループに対してクエリーを実行することで、そのグループに属するユーザーのリストを取得できます。

IBM Cloud Dedicated または Local にユーザーをプロビジョニングするために、管理コンソールでは、グループなどのフィーチャーを利用するとともに便利で使いやすいユーザー・インターフェースを提供して、ユーザー、グループ、グループのメンバーを検索できるようになっています。

ユーザーを検索するためにユーザー名を検索ボックスに入力すると、IBM Cloud コンソールにもその名前が表示されます。IBM Cloud 環境では、名、姓、メール・アドレスを読み取るために LDAP 属性が必要になります。

図 2. ユーザーを IBM Cloud Dedicated または Local 環境に追加する際の管理コンソール
ユーザーを追加する際の管理コンソールのスクリーンショット
ユーザーを追加する際の管理コンソールのスクリーンショット

SAML

利用できる環境: Public、Local

SAML (Security Assertion Markup Language) はオープン・スタンダートのデータ形式です。SAML では、アイデンティティー・プロバイダー (認証サーバー) とサービス・プロバイダー (アプリケーションまたはサービス) との間で交換される認証・許可情報に XML ドキュメント形式を使用します。SAML を使用すると、さまざまな Web アプリケーションにまたがるシングル・サインオンが可能になります。

アイデンティティー情報の送信

SAML 認証サーバー (アイデンティティー・プロバイダー) はユーザーに関する情報とその他の属性を、「SAML アサーション」と呼ばれる XML ドキュメントに含めて SAML クライアント (サービス・プロバイダー) に送信します。誰もアイデンティティーを偽造できないように、SAML アサーションには暗号化署名が付けられます。また、SAML アサーションの内容が中間コンポーネントに不明瞭になるように、アイデンティティー・プロバイダーがさらに SAML アサーションを暗号化することもできます。

以下に示す SAML レスポンスは、SAML サービス・プロバイダーに送信された、ID が 3f7b3dcf-1674-4ecd-92c8-1544f346baf8 のユーザーに関するアサーションの例です。

リスト 5. SAML レスポンスの例
<samlp:Response xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol" 
                   xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion" 
                   ID="identifier_2" InResponseTo="identifier_1" 
                   Version="2.0" IssueInstant="2004-12-05T09:22:05Z" 
                   Destination="https://sp.example.com/SAML2/SSO/POST">
                
<saml:Issuer>https://idp.example.org/SAML2</saml:Issuer>
<samlp:Status>
  <samlp:StatusCode Value="urn:oasis:names:tc:SAML:2.0:status:Success"/>
</samlp:Status>

<saml:Assertion xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion" 
                  ID="identifier_3" Version="2.0" 
                  IssueInstant="2004-12-05T09:22:05Z">
<saml:Issuer>https://idp.example.org/SAML2</saml:Issuer>
    <!-- a POSTed assertion MUST be signed -->
    <ds:Signature xmlns:ds="http://www.w3.org/2000/09/xmldsig#">...</ds:Signature>
      <saml:Subject>
        <saml:NameID Format="urn:oasis:names:tc:SAML:2.0:nameid-format:transient">
          3f7b3dcf-1674-4ecd-92c8-1544f346baf8
      </aml:NameID>
      <saml:SubjectConfirmation Method="urn:oasis:names:tc:SAML:2.0:cm:bearer">
          <saml:SubjectConfirmationData InResponseTo="identifier_1" 
                                    
Recipient="https://sp.example.com/SAML2/SSO/POST" 
                                    NotOnOrAfter="2004-12-05T09:27:05Z"/>
        </saml:SubjectConfirmation>
      </saml:Subject>
      <saml:Conditions NotBefore="2004-12-05T09:17:05Z" 
                       NotOnOrAfter="2004-12-05T09:27:05Z">
        <saml:AudienceRestriction>
          <saml:Audience>https://sp.example.com/SAML2</saml:Audience>
        </saml:AudienceRestriction>
      </saml:Conditions>
      <saml:AuthnStatement AuthnInstant="2004-12-05T09:22:00Z" 
                           SessionIndex="identifier_3">
        <saml:AuthnContext>
          <saml:AuthnContextClassRef>
            urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport
          </saml:AuthnContextClassRef>
      </saml:AuthnContext>
    </saml:AuthnStatement>
  </saml:Assertion>
</samlp:Response>

注: 上記のサンプル・コードは、「OASIS SAML V2.0 Technical Overview」から引用しています。

信頼を確立する方法

アプリケーションまたはサービス (サービス・プロバイダー) と SAML 認証サーバー (アイデンティティー・プロバイダー) が連携するには、その前に、サービス・プロバイダーの管理者とアイデンティティー・プロバイダーの管理者が、関連するコンポーネントのすべての必須パラメーターを記述するメタデータをインポートまたは参照する必要があります。

このメタデータには、以下に関する情報が含まれます。

  • ログインするために必要なエンドポイント
  • SAML アサーションに含めて送信される情報
  • SAML アサーションの署名を検証するために使用する証明書/公開鍵 (通信方向: アイデンティティー・プロバイダー -> サービス・プロバイダー)
  • 必要に応じて、SAML アサーションを復号化するために使用する証明書/公開鍵 (通信方向: アイデンティティー・プロバイダー -> サービス・プロバイダー)
  • SAML 認証要求を復号化するために使用する証明書/公開鍵 (通信方向: サービス・プロバイダー -> アイデンティティー・プロバイダー)

IBM Cloud での SAML の使用法

IBM Cloud に SAML アイデンティティー・プロバイダーを設定して、そのプロバイダーが署名した SAML アサーションを信頼するように構成することができます。このように構成した場合、ユーザーがサインインする際の流れは以下のようになります。

図 3. SAML 認証の概要
SAML 認証フローの概要を示す図
SAML 認証フローの概要を示す図

SAML アサーション内に含まれているアイデンティティーは、ログイン済みユーザーと見なされます。SAML アサーションに含まれるそれ以外の情報は、IBM Cloud によって使用されません。

クライアントと認証方式

ブラウザー・ベースの IBM Cloud クライアントの場合の認証

IBM Cloud コンソールは、ブラウザー・ベースのアプリケーションです。IBM Cloud 内では、ユーザーの認証に OAuth 2.0 プロトコルが使用されます。つまり、IBM Cloud 認証コンポーネントは IBM Cloud コンソールに対し、ユーザーのアイデンティティーを含めた OAuth 2.0 トークンを発行します。このことは、どの認証方式を選択したとしても変わりません。

図 4. ブラウザー・ベースの IBM Cloud クライアントの場合の一般的な認証フロー
UI での認証フローを示す図
UI での認証フローを示す図

IBMid または SAML の場合、IBM Cloud 認証コンポーネントはユーザーのブラウザーを別のサーバーにリダイレクトし、そのサーバーのレスポンスからユーザーのアイデンティティーを取得します。LDAP の場合、IBM Cloud 認証コンポーネントはユーザー名とパスワードを入力するための HTML ダイアログを表示し、単独で LDAP に認証情報を照合して検証します。認証方式の選択において、ユーザーにとっての使い勝手は重要ではありません。

コマンド・ラインおよびネイティブ・アプリケーションの場合の認証

IBM Cloud 認証を利用するネイティブ・アプリーションとしては、以下のアプリケーションが広く知られています。

上記の 2 つを含め、すべてのアプリケーションがブラウザー・ベースのやりとりで IBM Cloud に対する認証を行って以下の共通の特性を共有するわけではありません。

  • 資格情報の要求: ネイティブ・アプリケーションはそれぞれに独自のダイアログを表示してユーザー名とパスワードの入力を求めます。資格情報を提供する際は、アプリケーションのソースを信頼しなければならないことに注意してください。このアプリケーションのマルウェア・バージョンが資格情報をキャプチャーするかもしれません。
  • 認証情報の検証: これらのアプリケーションは OAuth 2.0 の「パスワード付与」メソッドを使用して、ユーザー名とパスワードを直接 IBM Cloud 認証コンポーネントに送信します。

IBM Cloud 認証コンポーネントは、可能な場合はバックエンドの認証サーバーにユーザー名とパスワードを送信します。この方法は、IBMid にフェデレーションおよび LDAP 認証方式を使用しないのであれば有効ですが、フェデレーションを使用する IBMid や SAML を統合した IBM Cloud 環境には無効です。基礎となる認証プロトコルは、互換性のある認証メカニズムをサポートしていません。

これらのクライアントが IBM Cloud (および構成) を使用して認証を行えるようにするには、Web ブラウザーを使用して、アプリケーションにログインするための「一度限りのパスコード」を取得するという方法があります。このようにログインする場合、ネイティブ・アプリケーションが、このタイプのやりとりをサポートする必要があります。以下のフロー図に、これらの環境用の正常なログインの流れを示します。

図 5. 一度限りのパスコードを使用した認証フロー
一度限りのパスワードを使用した認証フローを示すスクリーンショット
一度限りのパスワードを使用した認証フローを示すスクリーンショット

まとめ

まとめとして、4 つの異なる認証メソッドそれぞれの特性を 1 つの表に記載します。

表 1. 認証方式ごとの特性
IBMidフェデレーテッド・ユーザーを使用した IBMidLDAPSAML
利用できる環境
IBM Cloud PublicXX
IBM Cloud DedicatedXXXX
IBM Cloud LocalXXX
接続性
VPN が必要Dedicated では必要になることが多い
Dedicated/Local 内でのユーザー・プロビジョニング
ユーザー検索の容易さX
グループ・メンバー検索の容易さX
ユーザー詳細の手入力XXX
パスワード管理およびポリシー
IBMX
顧客XXX
サポートされるアプリケーションのタイプ
ブラウザー・ベースXXXX
資格情報を使用した CLI/ネイティブXX
一度限りのパスコードを使用した CLI/ネイティブXXXX
顧客提供の 2 要素認証への対応XX
再ログインなしの IBM Cloud Public に対する認証XX

付録

IBMid/フェデレーテッド・ユーザーを使用した IBMid に必要な情報

IBMid は、IBM Cloud Public 内ではデフォルトでアクティブになり、IBM Cloud Dedicated および Local では詳細情報を入力せずに選択できるようになっています。

SAML アイデンティティー・プロバイダーに IBMid を統合する場合は、このリンク先のページで説明されているプロセスに従う必要があります。

フェデレーション・プロセスのステップは、Dedicated または Local インスタンスの構成とは関係しないため、IBM Cloud 環境を顧客用に構成する前でも構成した後でも実行できます。

LDAP に必要な情報

Dedicated または Local 環境を構成するために必要な一般情報、LDAP に接続するための情報、ユーザーの情報、ユーザーの検索およびログインに必要な情報、グループの情報、そしてプラットフォームの管理を容易にするためにグループを検索するための情報を、以降の表にまとめます。

表 2. 一般
属性説明標準的な値使用する値
objectClassLDAP サーバーに接続するための LDAP エンドポイントldaps://ldap.company.com
ldap://10.1.2.3
msadgcUrl (任意)Microsoft Active Directory サーバーを使用している場合、必要に応じてグローバル・カタログ・エンドポイントの URL を指定して最適化を図ることができます。ldaps://ldap.company.com:3269
ldap://10.1.2.3:3268
userID (任意)検索を可能にする userId / bindDn を指定します。シンプルな認証が使用されます。myUserName CN=John.Doe,OU=users,OU=root
password (任意)検索を可能にするパスワードを指定します。シンプルな認証が使用されます。pa5sw0r!
表 3. ユーザー
属性説明標準的な値使用する値
objectClassユーザー・エントリーを検索するために使用する objectClass の名前inetOrgPerson person
userNameAttrユーザー名を取得するための LDAP 属性uid
userPrincipalName
mailAttrメールを取得するための LDAP 属性。空にすることはできません。mail
firstNameAttrユーザーの名を取得するための LDAP 属性givenName
lastNameAttrユーザーの姓を取得するための LDAP 属性sn
searchContextユーザーを検索するためのベース DNOU=users,OU=root
表 4. グループ
属性説明標準的な値使用する値
groupObjectClassグループ・エントリーを検索するために使用する objectClass の名前groupOfNames
groupOfUniqueNames
groupNameAttrグループ名を取得するための LDAP 属性cn
groupMemberAttrグループ・メンバーを取得するための LDAP 属性member
uniqueMember
groupSearchContextグループを検索するためのベース DNOU=groups,OU=root

LDAP サーバーが自己署名証明書または内部認証局の署名付き証明書を使用している場合、LDAPS 接続を許可するには、その証明書が必要です。

SAML に必要な情報

IBM Cloud Dedicated 環境を顧客の SAML アイデンティティー・プロバイダーに直接接続するには、以下の情報が必要です。

  • SAML アイデンティティー・プロバイダーのメタデータ (ファイルまたは URL)
  • 署名アルゴリズム (デフォルト: SHA256)
  • 任意: SAML アイデンティティー・プロバイダーの SSO セッション (ブラウザー) を無効にするために使用する URL

IBM Cloud Dedicated 環境チームは以上のデータを受け取った後、該当する SAML サービス・プロバイダーのメタデータ (SP メタデータ) ファイルを生成し、顧客に送信します。IBM Cloud Dedicated 環境からの要求を有効にするには、SAML アイデンティティー・プロバイダーの管理者がこの SP メタデータ・ファイルをインポートする必要があります。


ダウンロード可能なリソース


関連トピック


コメント

コメントを登録するにはサインインあるいは登録してください。

static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=60
Zone=セキュリティ
ArticleID=1052894
ArticleTitle=ハイブリッド・クラウドに使用する認証方式を把握する
publish-date=11302017