ID に関する用語
学習の目的
- ID およびアクセス管理に使用される業界標準を識別する。
- SAML と XML がどう関連するかを理解する。
- ID プロバイダーとサービスプロバイダーの違いを理解する。
ID の標準とプロトコル
次に挙げるのは、Salesforce や他の ID ベンダーが ID ソリューションを実装する際に従っている 3 つのプロトコルです。
- SAML
- OAuth2.0
- OpenID Connect
SAML プロトコル
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 プロトコル
たとえば、次のような例があります。
- Salesforce 組織から取引先責任者を取り込むモバイルアプリケーションは OAuth を使用します。
- 別のサービスから取引先責任者を取得する Salesforce 組織も OAuth を使用します。
次の例では、アプリケーションがユーザーに OAuth 2.0 を使用して情報にアクセスする許可を要求しています。
OpenID Connect プロトコル
アプリケーション開発者は OpenID Connect プロトコルを使用してソーシャルサインオンを有効にします。
たとえば、Google が別のサービスに代わってユーザーの ID を検証するとき、Google がユーザーを認証します。ここでは、Google は ID プロバイダーです。
Salesforce には、Google、Facebook、LinkedIn など、複数の主要なソーシャル ID プロバイダーのサポートが組み込まれています。プロバイダーが標準でサポートされていない場合でも、Amazon や PayPal のようにプロバイダーが OpenID Connect プロトコルを実装していれば使用できます。
ユーザーにとって OpenID Connect プロトコルには、別々のアカウント、ユーザー名、パスワードの数を減らせるというメリットがあります。一方で、開発者は、パスワードファイルを所有して管理することなく、複数の Web サイトやアプリケーションにまたがってユーザーを認証できます。このプロセスにより、ハッカーによるユーザーアカウントの侵害がはるかに難しくなります。
サービスプロバイダーと ID プロバイダー
ユーザーは ID プロバイダーからログインし、Salesforce (サービスプロバイダー) にリダイレクトされます。別のモジュールでは、Salesforce をサービスプロバイダー、サードパーティアプリケーションを外部 ID プロバイダーとして SSO を設定します。
Salesforce が ID プロバイダーの場合SSO の SAML フロー
- ユーザーが Salesforce へのアクセスを試みる。
- Salesforce が SSO 要求を認識し、SAML 要求を生成する。
- Salesforce が SAML 要求を元のブラウザーにリダイレクトする。
- ブラウザーが SAML 要求を外部 ID プロバイダーにリダイレクトする。
- ID プロバイダーがユーザーの ID を検証し、ユーザー認証を含む SAML アサーションをパッケージ化する。
- ID プロバイダーが SAML アサーションをブラウザーに送信する。
- ブラウザーがアサーションを Salesforce にリダイレクトする。
- Salesforce がアサーションを検証する。
- ユーザーのサインインが許可され、Salesforce にアクセスできるようになる。
ID 用語の早見表
Salesforce の用語 | 間違えやすい用語 |
---|---|
認証とは、「誰であるか」を確認することです。最近では、「承認と認証」を短縮して「認証」が使用される多いです。 | 承認とは、「ある特定の権限を持っているか」を確認することです。 |
プロトコルとは、システムが情報を交換するためのルールセットを指します。一般的に、「プロトコル」と「標準」という用語はほとんど同義です。 | 標準とは、ベンダーがサポートすることに同意した業界慣行の仕様です。標準には、企業が標準を実装する方法を指定するためにプロトコルが含まれることがよくあります。 |
ユーザー名とパスワードは、ユーザーがシステムにログインするために指定するものです。 | ログイン情報もほとんど同じ意味です。 |
シングルサインオン (SSO) を使用すると、ユーザーは 1 回ログインすれば、再びログインすることなく他のアプリケーションやサービスにアクセスできます。 | ソーシャルサインオンを使用すると、ユーザーは Google などのソーシャルアカウントで確立されたログイン情報を使用してアプリケーションにログインできます。そのアプリケーションは Google ログイン情報を受け入れ、ユーザーは別のアカウントとパスワードを作成する必要がありません。 |
ID プロバイダーは、ユーザーが再びログインせずに Web サイトやサービスにアクセスできるようにする信頼されたサービスです。 | サービスプロバイダーは、アプリケーションをホストする Web サイトやサービスで、ID プロバイダーからの ID を受け入れます。 |