ID に関する用語

学習の目的

このモジュールを完了すると、次のことができるようになります。

• ID およびアクセス管理に使用される業界標準を識別する。
  
• SAML と XML がどう関連するかを理解する。
  
• ID プロバイダーとサービスプロバイダーの違いを理解する。
  

ID の標準とプロトコル

外部 Web サイトやアプリケーションにサインインせずにユーザーの ID を安全に保護できるとは信じがたいですか? 多くの企業の製品が、競合する製品も含めて、連携できるのはどうしてなのでしょう?

その答えが、ID およびアクセス管理のための業界標準とプロトコルです。難しそうに聞こえますが、そんなことはありません。標準とは、広い範囲の業界メンバーがそれに従うことに同意している一連の慣行です。標準には、システムが情報を交換する方法を指定する、プロトコルが含まれていることがあります。

次に挙げるのは、Salesforce や他の ID ベンダーが ID ソリューションを実装する際に従っている 3 つのプロトコルです。

• SAML
  
• OAuth2.0
  
• OpenID Connect
  

SAML プロトコル

ユーザーが繰り返しログインせずに Salesforce 組織とアプリケーションの間をシームレスに移動できるようにするには、シングルサインオン (SSO) を設定します。Security Assertion Markup Language (SAML) は、SSO を可能にするプロトコルです。

SAML が機能する例として次のようなものがあります。

• Salesforce にログインし、アプリケーションランチャーをクリックして Gmail の受信トレイを直接表示する場合、SAML が機能しています。
  
• すでに別のアプリケーションにログインしているユーザーが再びログインせずに Salesforce 組織にログインできる場合、SAML が機能しています。
  

SAML アサーション

SAML の動作の流れを説明すると、まずユーザーがサービスにアクセスしようとします。サービスプロバイダーは、「このユーザーがこちらのサービスにアクセスしたいらしいけれど、大丈夫?」と尋ねる要求を ID プロバイダーに送信します。ID プロバイダーはデータベースをチェックし、「このユーザーは認証済みですね。これがその情報です。」と応答 (アサーション) を返してユーザーの身元に偽りがないことを確認します。

さて、ここで質問です。ID プロバイダーとサービスプロバイダーは何が違うのでしょう。基本的に、ID プロバイダーはユーザーを認証します。サービスプロバイダーは認証された ID を要求します。ID プロバイダーとサービスプロバイダーについては、この単元の後で詳しく取り上げます。

アサーションは送信される情報です。アサーションには、ユーザーに関する詳細な情報を含めることができます。氏名、連絡先情報、さらに役職など、ユーザーに関する属性も含めることができます。

SAML はバックグラウンドで動作します。ユーザーの目には触れません。ユーザーがアイコンまたはリンクをクリックするだけで、追加の情報を入力したり、再びログインしたりしなくても別のアプリケーションが開きます。対象にアクセスすると、すでにユーザーに関する情報 (ユーザー属性) が認識されていることもあります。

SAML と XML

SAML は XML ベースのプロトコルです。つまり、交換される情報のパッケージは XML で記述されています。XML は (ほとんどの場合) 人間が読み取れるため、何が起こっているのか把握できます。正しく動作しているか解明しようとする場合、これは便利です。

次の図は、SAML アサーションの一部を示しています。意味不明に見えますか? もう一度見てみましょう。少しわかるかもしれません。ユーザーのユーザー名、電話番号、名に関する情報が含まれています。

この例では、Salesforce 組織はユーザーの情報を別のアプリケーションに渡します。アプリケーションはその情報を使用してユーザーを承認し、ユーザーのエクスペリエンスをパーソナライズできます。だたし、最も重要なのは、ユーザーが再びサインインせずにアプリケーションにアクセスできることです。

OAuth 2.0 プロトコル

OAuth (オープン認証) 2.0 は、アプリケーション間のセキュアなデータ共有を可能にするために使用するオープンプロトコルです。ユーザーは、一方のアプリケーションで作業し、もう一方のアプリケーションからデータを表示できます。たとえば、Salesforce モバイルアプリケーションにログインし、Salesforce 組織からデータを表示できます。

アプリケーションはバックグラウンドで一種のハンドシェイクを実行してから、ユーザーにこのデータ共有を承認するように要求します。開発者がアプリケーションを Salesforce に統合する場合は、OAuth API を使用します。

たとえば、次のような例があります。

• Salesforce 組織から取引先責任者を取り込むモバイルアプリケーションは OAuth を使用します。
  
• 別のサービスから取引先責任者を取得する Salesforce 組織も OAuth を使用します。
  

次の例では、アプリケーションがユーザーに OAuth 2.0 を使用して情報にアクセスする許可を要求しています。

OpenID Connect プロトコル

OpenID Connect プロトコルでは、ユーザー情報を安全に交換できるように、OAuth 2.0 上に認証レイヤーを追加します。OpenID Connect が 1 つのサービスから別のサービスに ID 情報を送信する点は SAML と同じですが、SAML との違いは、OpenID Connect が今日のソーシャルネットワーク環境用に構築されていることです。新しいアプリケーションをインストールしたときに「Google アカウントでログインしますか?」というメッセージが表示されたことはありませんか? そのアプリケーションは OpenID Connect プロトコルを使用しています。Google でサインインするときには、アカウントや別のパスワードを作成しません。その情報を保持しているのは Google だけです。

アプリケーション開発者は OpenID Connect プロトコルを使用してソーシャルサインオンを有効にします。

たとえば、Google が別のサービスに代わってユーザーの ID を検証するとき、Google がユーザーを認証します。ここでは、Google は ID プロバイダーです。

Salesforce には、Google、Facebook、LinkedIn など、複数の主要なソーシャル ID プロバイダーのサポートが組み込まれています。プロバイダーが標準でサポートされていない場合でも、Amazon や PayPal のようにプロバイダーが OpenID Connect プロトコルを実装していれば使用できます。

ユーザーにとって OpenID Connect プロトコルには、別々のアカウント、ユーザー名、パスワードの数を減らせるというメリットがあります。一方で、開発者は、パスワードファイルを所有して管理することなく、複数の Web サイトやアプリケーションにまたがってユーザーを認証できます。このプロセスにより、ハッカーによるユーザーアカウントの侵害がはるかに難しくなります。

サービスプロバイダーと ID プロバイダー

ユーザー認証プロセスで、SAML は ID 情報を ID プロバイダー (IDP) と呼ばれる情報保有者とサービスプロバイダーと呼ばれる目的のサービスの間で交換します。

ユーザーが Salesforce にログインしてから Gmail にアクセスする場合、Salesforce が ID プロバイダーで Google がサービスプロバイダーです。Salesforce はサービスプロバイダーと ID プロバイダーのどちらにもなれます。

Salesforce がサービスプロバイダーの場合

認証されたユーザーは外部 ID プロバイダーから Salesforce にアクセスできます。この場合、Salesforce がサービスプロバイダーです。ユーザーはこのサービスへのアクセス権を取得する必要があり、ID プロバイダーがそれを許可します。会社ですでに ID プロバイダーが使用されていることが多いため、このような Salesforce 設定は一般的です。ID プロバイダーとしては、Microsoft の Active Directory フェデレーションサービス (ADFS) や、Ping Identity の PingFederate、オープンソースの Shibboleth、ForgeRock の OpenAM など、市場にある既存のプロバイダーのいずれかが考えられます。

ユーザーは ID プロバイダーからログインし、Salesforce (サービスプロバイダー) にリダイレクトされます。別のモジュールでは、Salesforce をサービスプロバイダー、サードパーティアプリケーションを外部 ID プロバイダーとして SSO を設定します。

Salesforce が ID プロバイダーの場合

認証されたユーザーは Salesforce から他のクラウドやアプリケーションにアクセスできます。この場合、Salesforce は ID プロバイダーとして機能し、SSO を提供して、ユーザーが別のサービスプロバイダーに接続することを可能にします。

SSO の SAML フロー

参考までに、次の図は SSO プロセス中の SAML 通信フローを示します。バックグラウンドではこのようなことが行われています。興味がわかなくても心配いりません。テストには出ません。

SSO プロセスは目にもとまらぬ速さで実行されますが、実は複数の処理が行われています。

1. ユーザーが Salesforce へのアクセスを試みる。
   
2. Salesforce が SSO 要求を認識し、SAML 要求を生成する。
   
3. Salesforce が SAML 要求を元のブラウザーにリダイレクトする。
   
4. ブラウザーが SAML 要求を外部 ID プロバイダーにリダイレクトする。
   
5. ID プロバイダーがユーザーの ID を検証し、ユーザー認証を含む SAML アサーションをパッケージ化する。
   
6. ID プロバイダーが SAML アサーションをブラウザーに送信する。
   
7. ブラウザーがアサーションを Salesforce にリダイレクトする。
   
8. Salesforce がアサーションを検証する。
   
9. ユーザーのサインインが許可され、Salesforce にアクセスできるようになる。
   

ID 用語の早見表

ID プロトコルに関する速習コースはいかがでしたか? 用語の響きが似ていて違いが微妙な場合、正しく覚えておくのは難しいかもしれません。そこで、早見表を用意しました。ぜひ活用してください。

次のステップ

ID アクセスと管理の業界標準を駆け足で見てきました。まだ頭の中で整理がついていなくても大丈夫です。現時点では、Salesforce Identity がプロトコルを使用して機能を実装することだけを覚えておいてください。

お楽しみはこれからです。概念と定義はもう十分ですね。これまでに学んだことを実践してみましょう。このトレイルでは、後で Salesforce 開発組織にセキュリティ機能を設定します。

リソース

• Salesforce ヘルプ: SAML SSO フロー
  
• Salesforce ヘルプ: ユーザーの識別およびアクセス権の管理