クラウドとの認証連携

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 Weekly」の配信サービスを提供しています。メルマガ会員登録を済ませれば、メルマガだけでなく、さまざまな限定特典を入手できるようになります。

Think ITメルマガ会員のサービス内容を見る

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