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

SAML アサーション

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

OAuth 2.0 プロトコル

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

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

次は、その例です。

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

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

例の Oauth ログ

OpenID Connect プロトコル

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

アプリケーション開発者は 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 プロバイダにできます。

ユーザは 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 にアクセスできます。
SSO の SAML 要求のフロー

ID 用語の早見表

ID プロトコルに関する速習コースはいかがでしたか? 用語の響きが似ていて違いが微妙な場合、正しく覚えておくのは難しいかもしれません。そこで、早見表を用意しました。ぜひ活用してください。
Salesforce の用語 間違えやすい用語
認証とは、ユーザが誰であるかという意味です。最近では、「承認および認証」を短縮して「認証」を使用する場合もよくあります。 承認とは、ユーザができることを示したものです。
プロトコルとは、システムが情報を交換するためのルールセットを指します。一般的に、「プロトコル」と「標準」という用語はほとんど同義です。 標準とは、ベンダーがサポートすることに同意した業界慣行の仕様です。標準には、企業が標準を実装する方法を指定するためにプロトコルが含まれることがよくあります。
ユーザ名とパスワードは、ユーザがシステムにログインするために指定するものです。 ログイン情報もほとんど同じ意味です。
シングルサインオン (SSO) を使用すると、ユーザは 1 回ログインすれば、再びログインすることなく他のアプリケーションやサービスにアクセスできます。 ソーシャルサインオンを使用すると、ユーザは Google などのソーシャルアカウントで確立されたログイン情報を使用してアプリケーションにログインできます。そのアプリケーションは Google ログイン情報を受け入れ、ユーザは別のアカウントとパスワードを作成する必要がありません。
ID プロバイダは、ユーザが再びログインせずに Web サイトやサービスにアクセスできるようにする信頼されたサービスです。 サービスプロバイダは、アプリケーションをホストする Web サイトやサービスで、ID プロバイダからの ID を受け入れます。

次のステップ

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

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

無料で学習を続けましょう!
続けるにはアカウントにサインアップしてください。
サインアップすると次のような機能が利用できるようになります。
  • 各自のキャリア目標に合わせてパーソナライズされたおすすめが表示される
  • ハンズオン Challenge やテストでスキルを練習できる
  • 進捗状況を追跡して上司と共有できる
  • メンターやキャリアチャンスと繋がることができる