皆さんは社内・社外問わず、様々なシステム、サービスを使われていると思います。 その数が多ければ多いほど、そのIDやパスワードをそれぞれ管理する手間も煩雑になります。

Salesforceには便利なシングルサインオンの機能が備わっていて、社内システムのIDでSalesforceにもログインしたり、逆にSalesforceのIDとパスワードで他のシステムにもログインしたりすることが可能です。 日本国内では意外とシングルサインオン対応の要件はまだまだ少ないように思います。 ここでは、Salesforceで利用できるシングルサインオンについて、取り上げたいと思います。

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

シングルサインオンの仕組みについて理解する上で、IDプロバイダ（IdP）とサービスプロバイダ（SP）の位置付けの理解が第一に必要です。

ユーザIDやパスワードを保管していて、実際にユーザが入力したIDとパスワードを確認（認証）するサーバをIDプロバイダ、認証されたユーザが利用するサービスを提供する側をサービスプロバイダと呼びます。

例えば社内ポータルにログインすると、そこからSalesforceも再ログインすること無しに利用できる仕組みの場合、社内ポータルがIDプロバイダ、Salesforceがサービスプロバイダとなります。

SAML

Webベースのシングルサインオンの中で特にメジャーな方式がSAMLであり、SalesforceもSAMLによるシングルサインオンに対応しています。

SAMLでは、IDプロバイダが発行するアサーション（Assertion）と呼ばれる通行手形を、サービスプロバイダに提示することで、サービスプロバイダ側はユーザが認証済の正規ユーザであることを確認します。

先ほど例に上げた、社内ポータル→Salesforceのシングルサインオンの場合、IDプロバイダに先にログインしてから、Salesforceにアサーションを渡して認証していますので、この方式をIdP-Initiatedのシングルサインオンと呼びます。

逆にSalesforceにアクセスしようとすると、自動的に社内ポータルのログイン画面に転送され、そこで社内ポータルのユーザIDとパスワードを送信すると、Salesforceにログインされるようなシングルサインオンも実現できます。 こちらの場合、サービスプロバイダ側からスタートする認証フローですので、SP-Initiatedのシングルサインオンとなります。 この際、Salesforceはマルチテナントのアーキテクチャのため、ログインする組織を特定するために、マイドメインの取得が必要となります。

Webベースとお話しましたが、SAMLでのシングルサインオンでは、社内ポータルだけでなく、ActiveDirectoryに参加するWindowsPCにログオンすることで、Salesforceにもシームレスにログインすることも可能です。 ただし、この場合はADFS（Active Directory Federation Service）という、Windows認証とSAML認証を仲介するサービスをサーバー管理者側で構築する必要があります。

OAuth

皆さんはWeb上のいくつかのサービスで、サービス独自のIDやパスワードを作成しなくても、FacebookやTwitterのIDとパスワードで利用できるものを見かけたことはありませんか？

また、スマートフォンでFacebookやTwitterを利用するアプリを使う時、初回にIDとパスワードを入力しておけば、次回以降はIDやパスワードを入力することなく、アプリを開くだけで直接サービスを利用できたりしませんか？ ここで使われている仕組みがOAuthと呼ばれるものになります。

OAuthはAPI経由でのサービス利用を許可するもので、初回の認証時には対象のサービスやアプリに対して、IDプロバイダ側の一定の範囲の情報を利用することを許可します。 「ユーザの代わりにTwitterへの投稿を許可」など、TwitterのAPIの全ての機能ではなく、一部の機能に限定して、外部のサービスやアプリに対してアクセスを許可するのがOAuthです。

一番代表的なのはChatterデスクトップやモバイルのSalesforce1やChatterアプリで、これらは必ず初回起動時や、バージョンアップによって、求める権限の範囲が変更された時には、IDとパスワードを入力した後に、ユーザの代わりにいくつかの権限を利用することを許可するか拒否するかを聞いてきます。

OAuthの場合は、正しく認証されるとトークンと呼ばれる通行手形が発行されます。 このトークンと、利用可能な権限の範囲や有効期限が一緒に管理されており、APIを呼び出すクライアント側は、トークンに定められた有効期限が切れるまでの間、トークンに定められた範囲内の権限でAPIにアクセスすることが可能なのです。

また、OAuthトークンは、セッションIDと同じく、Salesforce側のセッションタイムアウトで設定された時間が経過すると、期限切れとなります。 OAuthの認証フローでは、OAuthトークンと一緒に発行されるリフレッシュトークンと呼ばれる無期限のトークンを使用して、再度有効なトークンを取得し直す機能も持っています。

代理認証

代理認証はその名の通り、Salesforce自身はユーザが送信してきたIDとパスワードをSalesforce内では認証しません。 代わりに社内の認証サーバや他のサービス等の認証用WebサービスAPIに対して、そのまま投げて、そちらに代わりに認証して貰います。

SAMLのような規格化された認証方式に対応できないような認証サーバを運用している場合でも、この方式であれば、Webサービスのリクエストを受信し、認証し、認証結果を返すというインタフェースを用意することで、Salesforceとのシングルサインオンを実現することができます。

OpenID Connect

Winter'14より、SalesforceがOpenID Connectに対応しました。 OpenID Connectとは、OAuth2.0の技術をベースに、対応した著名なサービス（Google、Amazon、Yahoo! Japan、mixi等）を認証プロバイダとして（例えばGoogleのIDとパスワードで）Salesforceへもログインできるようにする仕組みです。

実際には、Salesforce側で認証プロバイダの設定（コンシューマキーやエンドポイントの設定）を行い、ユーザ情報の登録用のハンドラを用意します。 ユーザオブジェクトにはSAMLの統合IDと同じように、対応認証プロバイダ側のユーザを識別するキー情報を保持します。

OpenID Connectへの対応によって、企業内ポータル等のローカルのユーザID、パスワードだけでなく、世に広く利用されているサービスの認証情報をSalesforceや様々なサービスで利用することが可能になりました。

まとめ

このように、Salesforceは多彩なシングルサインオンに対応しており、うまく使い分けることでユーザの利便性を大きく向上させることができます。 では、具体的にこれらの認証方式をどのように使い分ければ良いのでしょうか？ どの方式はどういった場合に適用すれば良いのか、以下に簡単にまとめてみました。

ツイート