Create: 2014/04/13
LastUpdate: 2014/04/20
≪ メニューに戻るLastUpdate: 2014/04/20
「 [CentOS6][OpenAM10] WindowsDesktopSSO(統合Windows認証)」では、下図の環境を構築し、WindowsDesktopSSOを試しました。
ここでは、同じテスト環境とインターネットを使って、WindowsDesktopSSO+SAMLで Salesforce にSSOしてみます。
ユーザ端末:192.168.1.91(exdt01.example.com)
OpenAMサーバ:192.168.1.92(exam01.example.com)
リバースプロキシサーバ:192.168.1.93(exig01.example.com)
WEBサーバ:192.168.1.94(www.example.com)
LDAPサーバ:192.168.1.95(exdj01.example.com)
LDAPサーバ:192.168.1.95(exdj01.example.com)
ADサーバ:192.168.1.90(exad01.example.com)
SAML連携については、以下のサイトの説明が参考になります今回も、OpenAMのサブレルム(test01)を使用ます。
OpenAMがIdP(アイデンティティプロバイダ)、SalesforceがSP(サービスプロバイダ)になり、統合IDで SAML連携するように設定します。OpenAMのユーザとSalesforceのユーザは、メールアドレスで紐付くようにします。
1.OpenAM の証明書ファイル作成
Salesforceに登録するOpenAMの証明書を作成します。
OpenAMには、"test" という名前のテスト用の証明書がデフォルトで用意されています。
OpenAMサーバで以下のように keytool コマンド を実行すると証明書をみることができます。
# /usr/java/default/bin/keytool -list -v -keystore /usr/share/tomcat6/openam/openam/keystore.jks -keypass chageit -storepass changeit キーストアのタイプ: JKS キーストアのプロバイダ: SUN キーストアには 1 エントリが含まれます。 別名: test 作成日: 2008/07/17 エントリタイプ: PrivateKeyEntry 証明連鎖の長さ: 1 証明書[1]: 所有者: CN=test, OU=OpenSSO, O=Sun, L=Santa Clara, ST=California, C=US 発行者: CN=test, OU=OpenSSO, O=Sun, L=Santa Clara, ST=California, C=US シリアル番号: 478d074b 有効期間の開始日: Wed Jan 16 04:19:39 JST 2008 終了日: Sat Jan 13 04:19:39 JST 2018 証明書のフィンガープリント: MD5: 8D:89:26:BA:5C:04:D8:CC:D0:1B:85:50:2E:38:14:EF SHA1: DE:F1:8D:BE:D5:47:CD:F3:D5:2B:62:7F:41:63:7C:44:30:45:FE:33 署名アルゴリズム名: MD5withRSA バージョン: 1 ******************************************* *******************************************この証明書(test)は、SAML連携で使用できますが、本番環境で使用することは推奨されないので、今回は、新規で証明書(saml)を作成します。
OpenAMサーバで以下のようにコマンドを実行して公開鍵と識別名情報を含む自己署名証明書を作成します。
# /usr/java/default/bin/keytool -genkeypair -keyalg RSA -keysize 2048 -validity 365 -alias saml -dname "CN=saml,OU=OpenAM,O=Blue21,L=Oota-ku,ST=Tokyo,C=JP" -keystore /usr/share/tomcat6/openam/openam/keystore.jks -keypass changeit -storepass changeitこれで、OpenAMの管理画面で、署名鍵として "saml" の名称で選択できるようになります。
-keypass、-storepass で指定したパスワードは、/usr/share/tomcat6/openam/openam ディレクトリの .keypass、.storepass ファイルに暗号化された状態で格納されています。初期値が changeit です。間違えるとSAML連携に失敗します。
パスワードを変えたい場合は、マニュアルを参照してください。
次に証明書(saml)をファイルに保存します。
OpenAMサーバで以下のようにコマンドを実行します。
# /usr/java/default/bin/keytool -export -alias saml -file saml.cer -keystore /usr/share/tomcat6/openam/openam/keystore.jks -keypass changeit -storepass changeit 証明書がファイル <saml.cer> に保存されました。このファイル(saml.cer)は、Salesforce の設定で使用するのでPCにダウンロードしておきます。
2.OpenAMでトラストサークルとIdPの作成
OpenAM管理画面 > [共通タスク] タブをクリックすると、下図の画面が表示されます。
[ホストアイデンティティプロバイダの作成] をクリックします。
[レルム]、[署名鍵]、[新しいトラストサークル]を入力して、[設定]ボタンをクリックします。
[署名鍵]は、上記1で作成した exam01 を選択します。
下図の画面が表示されたらIdPの作成完了です。
[終了]ボタンをクリックします。
OpenAM管理画面 > [連携]タブをクリックすると、下図の画面が表示されます。
作成した、トラストサークルとIdPを見ることができます。
赤枠で示した IdP をクリックします。
[サービス]タブ をクリックすると下図の画面が表示されます。
ここで表示されているURLを Salesforce の設定で使用します。
3.Salesforce の設定
Salesforce の設定は、以下の準備が実施されていることを前提にして記載します。
3.1.SAMLシングルサインオン設定
上記2で作成したOpenAMのIdPと連携するように SAMLシングルサインオンの設定を行います。
[管理] > [セキュリティのコントロール] > [シングルサインオンの設定] をクリックすると下図の画面が表示されます。
[編集]ボタンをクリックします。
[SAML を有効化] をチェックして、[保存]ボタンをクリックします。
[新規]ボタンをクリックします。
以下の内容を入力して、[保存]ボタンをクリックします。
- [名前] ・・・ 任意
- [API参照名] ・・・ [名前]と同じ値
- [発行者] ・・・ 上記2で作成したIdPのエンティティ名
- [エンティティID] ・・・ https://<Salesforceの「私のドメイン」>
- [IDプロバイダの証明書] ・・・ 上記1で作成した証明書ファイル(saml.cer)
- [SAML ID種別] ・・・ "アサーションには、ユーザオブジェクトの統合IDが含まれます"
- [SAML IDの場所] ・・・ "IDは、SubjectステートメントのNameIdentifier要素にあります"
- [IDプロバイダのログインURL] ・・・ 上記2のIdpの[サービス]タブにある、シングルサイオンサービス(POST)のURL
- [IDプロバイダのログアウトURL] ・・・ "http://exam01.example.com:8080/openam/UI/Logout"
- [サービスプロバイダの起動要求バインド] ・・・ "HTTPポスト" ※[IDプロバイダのログインURL]に合わせる
上記で[保存]ボタンクリック後は、下図のように表示されます。
[メタデータのダウンロード]ボタンをクリックして、メタデータをファイルに保存します。
メタデータは、OpenAMの設定で使用します。
[シングルサインオン設定に戻る]をクリックします。
下図のように表示されます。
3.2.ログインページのブランド設定
「私のドメイン」にアクセスしたときに、Salesforceのログインページは使用せず、SAML連携でシングルサインオンするように設定します。
[管理] > [ドメイン管理] > [私のドメイン]をクリックすると下図の画面が表示されるので、[ログインページのブランド設定] > [編集] ボタンをクリックします。
[ログインページ]のチェックを外し、[exam01]をチェックして[保存]ボタンをクリックします。
下図のように認証サービスが SAMLの exam01 を表示されたらOKです。
これで「私のドメイン」は、SSOに成功しないと使用できなくなります。
3.3.ユーザ設定
SAMLシングルサインオンの設定で、「統合ID」でSalesforce と OpenAMのユーザをマッピングするように設定したので、テストで使用するSalesforceユーザの「統合ID」にマッピング用の値を設定します。
今回は、マッピング用の値にメールアドレスを使用します。
今回のテストで使用するSalesforceユーザは、"user01@blue21demo.tk" とします。
このSalesforceユーザの「統合ID」に、紐つけたい OpenAMユーザのメールアドレスを設定します。
[管理] > [ユーザの管理] > [ユーザ] をクリックすると下図の画面が表示されます。
テストで使用するユーザの [編集] をクリックします。
[統合ID] にメールアドレスを入力して保存します。
今回使用するOpenAMユーザのメールアドレスは "demo@blue21demo.com" にします。
このメールアドレスは、あとで、紐つくOpenAMユーザのメールアドレスにも設定します。
4.OpenAMの設定
4.1.サービスプロバイダの登録
Salesforce をサービスプロバイダとして、OpenAM に登録します。
登録先のトラストサークルは、上記2で作成した test01_cot です。
※私の環境のOpenAM管理画面は、Chrome だと メタデータのアップロードボタンが反応しなかったので、IEで作業しています。
OpenAM管理画面 > [共通タスク]タブをクリックすると下図の画面が表示されるので、[リモートサービスプロバイダを登録]をクリックします。
[レルム]は "tset01" を選択し、[トラストサークル] は、"test01_cot" を選択します。
[メタデータファイル] は "ファイル" を選択して、上記3.1でダウンロードしたメタデータをアップロードします。
最後に[設定]ボタンをクリックします。
メッセージが文字化けしてますが、このバージョンのバグだと思います。
気にせず、[了解]ボタンをクリックします。
赤枠で示したように、SalesforceのSPが表示されたらOKです。
4.2.OpenAMでユーザマッピングの設定
OpenAMユーザとSalesforceユーザを紐つける設定を行います。
OpenAM管理画面 > [連携] をクリックすると下図の画面になるので、赤枠で示した IdP をクリックします。
下図の画面が表示されたら、[NameID値マップ] の "urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified" を削除して、"urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified=mail" を追加します。
入力できたら、[保存]ボタンをクリックします。
これで、OpenAMにログインしたユーザのメールアドレスでSSOするようになります。
4.3.ユーザ設定
今回のテストで使用するOpenAMユーザは "user01"です。
上記3.3で用意したSalesforceユーザと紐付くように、メールアドレスに "demo@blue21demo.com" を設定して、[保存]ボタンをクリックします。
4.動作確認
"EXAMPLE\user01" ユーザでユーザ端末にログインします。
下図は、リモートデスクトップでログインする場合の例です。
WindowsDesktopSSOの設定をしているので、WindowsにログインしたユーザでOpenAMは認証済みになります。
ブラウザで以下のSalesforceの「私のドメイン」にアクセスすると、OpenAMのログイン画面は表示されずに、Salesforceに自動的にログインします。
- https://blue21-dev-ed.my.salesforce.com
上記は、最初に Salesforce側の URL にアクセスしてSSOしたので、SP Initiated SSO になります。
最初に OpenAM側のURLにアクセスして、Salesforce にSSOする IdP Initiated SSO 試したい場合は以下のURLでアクセスします。各パラメータの意味は、マニュアルを参照してください。
なお、以下の例では、見やすいようにパラメータ値をURLエンコードしていませんが、パラメータ値はURLエンコードが必要です。
- http://exam01.example.com:8080/openam/saml2/jsp/idpSSOInit.jsp?metaAlias=/test01/idp&spEntityID=https://blue21-dev-ed.my.salesforce.com
■ 補足
SAMLのSSOに成功すると、OpenAMはLDAPに以下の赤枠で示した属性にデータを書き込みます。SAML連携の設定情報などをキャッシュしているようなのですが、OpenAMでSAML関連の設定を変更したときに、期待した動作にならないときは、このキャッシュが原因の可能性があります。赤枠の属性ごと削除して、キャッシュが無い状態でテストしてみると解決する場合があります。
LDAPの属性(下図の赤枠)を削除したあと、OpenAMを再起動すれば、OpenAMが保持しているキャッシュがすべて消えます。