クラウドとの認証連携
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の電文フォーマットと送信方法だけです。 |
---|
連載バックナンバー
Think ITメルマガ会員登録受付中
全文検索エンジンによるおすすめ記事
- クラウドの活用事例
- 恒例となったOSSセキュリティ技術の勉強会、今回はSSOソフトウェア「Keycloak」に注目!
- 注目のWebAuthnと公式より早いKeycloak最新動向を紹介!OSSセキュリティ技術の会 第5回勉強会
- クライアントポリシーを利用したKeycloakの設定方法と、FAPIリファレンス実装の紹介
- Keycloakの最前線を体感できるイベント「Keyconf 23」レポート
- シングルサインオン認証とは ー その種類と仕組み、メリット・デメリットを解説
- ForgeRockとの提携やOpenStandiaにみるNRIのオープンソース戦略
- クラウド環境とアイデンティティ/アクセス管理
- Keycloakを用いたハードニングの実装方法
- グルージェント、米国CloudLockの日本語版を販売開始