皆さんは社内・社外問わず、様々なシステム、サービスを使われていると思います。その数が多ければ多いほど、そのIDやパスワードをそれぞれ管理する手間も煩雑になります。Salesforceには便利なシングルサインオンの機能が備わっていて、社内システムのIDでSalesforceにもログインしたり、逆にSalesforceのIDとパスワードで他のシステムにもログインしたりすることが可能です。日本国内では意外とシングルサインオン対応の要件はまだまだ少ないように思います。ここでは、Salesforceで利用できるシングルサインオンについて、取り上げたいと思います。IDプロバイダとサービスプロバイダシングルサインオンの仕組みについて理解する上で、IDプロバイダ(IdP)とサービスプロバイダ(SP)の位置付けの理解が第一に必要です。ユーザIDやパスワードを保管していて、実際にユーザが入力したIDとパスワードを確認(認証)するサーバをIDプロバイダ、認証されたユーザが利用するサービスを提供する側をサービスプロバイダと呼びます。社内ポータルにログインすると、そこからSalesforceも再ログインすること無しに利用できる仕組みの場合、社内ポータルがIDプロバイダ、Salesforceがサービスプロバイダとなります。SAMLWebベースのシングルサインオンの中で特にメジャーな方式がSAMLであり、SalesforceもSAMLによるシングルサインオンに対応しています。SAMLでは、IDプロバイダが発行するアサーション(Assertion)と呼ばれる通行手形を、サービスプロバイダに提示することで、サービスプロバイダ側はユーザが認証済の正規ユーザであることを確認します。先ほど例に上げた、社内ポータル→Salesforceのシングルサインオンの場合、IDプロバイダに先にログインしてから、Salesforceにアサーションを渡して認証していますので、この方式をIdP-Initiatedのシングルサインオンと呼びます。逆にSalesforceにアクセスしようとすると、自動的に社内ポータルのログイン画面に転送され、そこで社内ポータルのユーザIDとパスワードを送信すると、Salesforceにログインされるようなシングルサインオンも実現できます。こちらの場合、サービスプロバイダ側からスタートする認証フローですので、SP-Initiatedのシングルサインオンとなります。この際、Salesforceはマルチテナントのアーキテクチャのため、ログインする組織を特定するために、マイドメインの取得が必要となります。Webベースとお話しましたが、SAMLでのシングルサインオンでは、社内ポータルだけでなく、ActiveDirectoryに参加するWindowsPCにログオンすることで、Salesforceにもシームレスにログインすることも可能です。Service)という、Windows認証とSAML認証を仲介するサービスをサーバー管理者側で構築する必要があります。ジャストインタイムユーザプロビジョニングSAMLによるシングルサインオンで、社内ポータルをIDプロバイダ、Salesforceをサービスプロバイダとした場合、社内ポータルのAさんのIDをSalesforce側では統合IDとして、ユーザAさんと紐付けて保存しています。Bさんを追加する場合、通常では社内ポータルへのBさんの登録とSalesforceへのBさんの登録の二重の作業が必要になります。ジャストインタイムユーザプロビジョニングを利用することで、これを省略して、社内ポータルへBさんを登録すると、Salesforceへも自動的にBさんのユーザを自動登録することが可能になります。具体的には、先ほど説明したSAMLアサーションに、Salesforce側でBさんのユーザを作成するために必要なメールアドレスや短縮名、ニックネームやロール、プロファイルのIDといった情報を一緒に含めてIdPが発行することで、受け取ったSalesforce側で、Bさんが未登録のユーザであった場合に、自動でユーザを作成することができます。ここで使われている仕組みがOAuthと呼ばれるものになります。OAuthはAPI経由でのサービス利用を許可するもので、初回の認証時には対象のサービスやアプリに対して、IDプロバイダ側の一定の範囲の情報を利用することを許可します。「ユーザの代わりにTwitterへの投稿を許可」など、TwitterのAPIの全ての機能ではなく、一部の機能に限定して、外部のサービスやアプリに対してアクセスを許可するのがOAuthです。代表的なのはChatterデスクトップやモバイルのSalesforce1やChatterアプリで、これらは必ず初回起動時や、バージョンアップによって、求める権限の範囲が変更された時には、IDとパスワードを入力した後に、ユーザの代わりにいくつかの権限を利用することを許可するか拒否するかを聞いてきます。OAuthの場合は、正しく認証されるとトークンと呼ばれる通行手形が発行されます。このトークンと、利用可能な権限の範囲や有効期限が一緒に管理されており、APIを呼び出すクライアント側は、トークンに定められた有効期限が切れるまでの間、トークンに定められた範囲内の権限でAPIにアクセスすることが可能なのです。OAuthトークンは、セッションIDと同じく、Salesforce側のセッションタイムアウトで設定された時間が経過すると、期限切れとなります。その名の通り、Salesforce自身はユーザが送信してきたIDとパスワードをSalesforce内では認証しません。代わりに社内の認証サーバや他のサービス等の認証用WebサービスAPIに対して、そのまま投げて、そちらに代わりに認証して貰います。SAMLのような規格化された認証方式に対応できないような認証サーバを運用している場合でも、この方式であれば、Webサービスのリクエストを受信し、認証し、認証結果を返すというインタフェースを用意することで、Salesforceとのシングルサインオンを実現することができます。Connectに対応しました。Japan、mixi等)を認証プロバイダとして(例えばGoogleのIDとパスワードで)Salesforceへもログインできるようにする仕組みです。実際には、Salesforce側で認証プロバイダの設定(コンシューマキーやエンドポイントの設定)を行い、ユーザ情報の登録用のハンドラを用意します。ユーザオブジェクトにはSAMLの統合IDと同じように、対応認証プロバイダ側のユーザを識別するキー情報を保持します。Connectへの対応によって、企業内ポータル等のローカルのユーザID、パスワードだけでなく、世に広く利用されているサービスの認証情報をSalesforceや様々なサービスで利用することが可能になりました。まとめこのように、Salesforceは多彩なシングルサインオンに対応しており、うまく使い分けることでユーザの利便性を大きく向上させることができます。どの方式はどういった場合に適用すれば良いのか、以下に簡単にまとめてみました。社内ポータルやActiveDirectoryとの認証統合。ユーザの職責によって権限を分けたい場合に使用。リソースの利用を限定させた認証。検索クラウドやるならテラスカイ。求む!Salesforce開発エンジニア。