PR

クラウドとの認証連携

2011年2月18日(金)
米川 和利

4. salesforceとの認証連携

ここでは社内ポータルとsalesforceとの認証連携を例としてSAMLの動作を説明します。SAMLでは、ユーザーを認証するサイトをIdentity Provider、サービスを提供するサイトをService Providerと呼びます。このため、社内ポータルとsalesforceは以下の関係となります。

図3:salesforceと社内ポータルのSAMLでの関係

4.1 事前準備(Identity Providerの名前と公開鍵の登録)

事前に、社内ポータル(Identity Provider)の名前と公開鍵をsalesforce(Service Provider)に登録しておく必要があります。この作業は、システムの導入時に一度だけ実行します。

図4:社内ポータルの名前と公開鍵をsalesforceへ登録(クリックで拡大)

社内ポータルの名前は、salesforce上で重複していなければ、どのような文字列でも構いません。例えば、下記のような社内ポータルのURLを名前として使用します。

http://iwsamlp.example.com

社内ポータルの公開鍵は、以下のようなJavaコマンドで作成します。

$ keytool -genkey -keystore keystore.jks -storepass password -alias alias 
-keypass password -keyalg rsa -keysize 1024 -validity 3650 -dname 
"CN=iwsamlp.example.com"
$ keytool -exportcert -rfc -keystore keystore.jks -storepass password 
-alias alias -file public.pem
ポイント(1) SAMLでは、相手のサイトを信頼する方法として、PKI(公開鍵基盤)を使用します。

ここで決定した社内ポータルの名前と、公開鍵をsalesforceの管理画面から事前に登録しておきます。

ポイント(2) SAMLでは、システム管理者がサイトの情報(サイトの名前や公開鍵など)を事前に交換しておきます。

4.2 事前準備(ユーザー情報の結びつけ)

事前に、社内ポータル(Identity Provider)では、社員のユーザーIDとsalesforce(Service Provider)のユーザーIDを結びつけておく必要があります(下図)。この作業は、salesforceにユーザーを追加するたびに実行します。

図5:salesforceのユーザー情報を結びつける(クリックで拡大)

例えば、データベースにRDBを使用している場合、以下のようなSQLコマンドで社員のユーザーIDにsalesforceのユーザーIDを結びつけます。

UPDATE icewalltest SET salesfid = 'sales-user-01' WHERE userid = 'user-a';
ポイント(3) SAMLでは、アプリケーション(この場合は社内ポータル)がどのようにユーザー情報を保持するかを規定していません。任意の方法で保持できます。
SAMLが規定しているのは、SAML電文のフォーマットと電文の送信方法だけです。

4.3 認証連携の実行

事前準備が済んでいれば、ユーザーは社内ポータル(Identity Provider)からsalesforce(Service Provider)へ認証連携できます。ユーザーが認証連携する流れを以下に示します。

図6:salesforceへ認証連携するシーケンス(クリックで拡大)
ポイント(4) 電文の流れは、SAMLの「Profiles」仕様書に記述されています。
番号 概要 内容
1 認証連携の開始 ユーザーは、salesforce(Service Provider)への認証連携を開始します。
2 社内ポータルによる認証 社内ポータル(Identity Provider)は、ユーザーが社内ポータルで認証済みであることを確認します。
3 SAMLレスポンスの生成 ユーザーが認証済みの場合、社内ポータルはSAMLレスポンスを生成します。次に、SAMLレスポンスに署名を付けます。
4 SAMLレスポンスの送信 社内ポータルは、ブラウザを経由して、SAMLレスポンスを、salesforceへ渡します。
5 認証連携の完了 salesforceは、SAMLレスポンスの署名を検証します。次に、SAMLレスポンス内の認証情報を確認します。認証情報に問題がなければ、ユーザーにsalesforceへのアクセスを許可します。

4.3.1 認証連携の開始

例えば、ユーザーはブラウザから以下のようなURLにアクセスします。

http://iwsamlp.example.com/sso

4.3.2 Identity Providerによる認証

社内ポータル(Identity Provider)は、以下を実行します。

  • 社内ポータルで認証済みのユーザーにSAMLレスポンスの生成を許可する
  • ユーザーが社内ポータルで未認証の場合、以下のようなログイン画面を表示して、ユーザーに認証を促す。

ログイン画面例
ポイント(5) SAMLでは、Identity Providerがどのようにユーザーを認証するか規定していません。Identity Providerは、任意の方法でユーザーを認証できます。
SAMLが規定しているのは、サイト間のSAMLの電文フォーマットと送信方法だけです。
日本ヒューレットパッカード株式会社

1995年 日立製作所に入社。システム、アプリケーション開発に従事。2001年より現職。
シングルサインオン、アイデンティティ管理、SAML・OpenIDの製品開発に従事する。
小学6年生の時に、カシオのPB-100が懸賞で当たったのがプログラミングの始まり。Javaをこよなく愛するが、最近は、PHPとC#が気になる。趣味は熱帯魚の飼育。週末は、妻と4歳の息子とで食べ歩き。
http://twitter.com/k_yonekawa

連載バックナンバー

Think IT会員サービス無料登録受付中

Think ITでは、より付加価値の高いコンテンツを会員サービスとして提供しています。会員登録を済ませてThink ITのWebサイトにログインすることでさまざまな限定特典を入手できるようになります。

Think IT会員サービスの概要とメリットをチェック

他にもこの記事が読まれています