こんにちは！たつみんです。
SalesfoceのSSO設定とプロビジョニングについて検証してみました。最後のパートではハマりやすいポイントについても解説しています。
それではいってみよう！
前提事項
今回はSalesforce側で事前にカスタムドメインを設定済みで、本番環境とは別にSandbox環境を作っていることを前提としています。今回はSandbox環境に対する設定を行う方法を記載しています。
SSO設定
Okta事前準備
- Okta管理画面へログインし、Applications>Applications>Browse App Catalogをクリックします。
- Salesforce.comをクリックし、Addをクリックします。
- App nameを入力し、Nextをクリックします。（ex.Salesforce-sandbox
- Instance TypeをSandboxを選択します。 本番環境に対する設定の場合はProductionを選択します。
- Custom Domainには設定している場合はサブドメイン部分入力します。 設定をしていない場合は何も入力しません。
- User Profile & TypeはStandard Salesforceを選択します。
- Sign OnタブでSAML 2.0を選択し、View Setup Instructionsをクリックします。
- 表示されるSAML設定手順に沿ってSalesforce側の設定も行います。
Salesforce設定
- 設定>ID>シングルサインオン設定を開きます。
- 編集をクリックし、SAML を有効化にチェックをいれます。
- SAML シングルサインオン構成で新規をクリックします。
- 下図のようにOKtaのSAML設定手順で表示された設定値や証明書をアップロードし設定後に保存をクリックします。
- 今回Entity IDについてはカスタムドメインを設定済みのため、以下の形式で設定を行います。
https://[customDomain].my.salesforce.com - SAML シングルサインオン構成で名前部分をクリックします。
- 表示されたログインURLをOkta Sign OnタブのAdvanced Sign-on SettingsのLogin URLに反映します。
- Salesforceでシングルログアウトを実施したい場合は以下の設定も実施します。
- 上で表示されたログアウトURLをOkta Sign OnタブのAdvanced Sign-on SettingsのLogout URLに反映します。
- メタデータのダウンロードを行いテキストエディタなどで開き、ds:X509Certificateの値部分のみをコピーします。
- コピーした値の先頭に—-BEGIN CERTIFICATE——を、最後に—-END CERTIFICATE——を追加し、ファイル名をslo.certとして保存します。
- Okta Sign OnタブのSAML 2.0内にあるEnable Single Logoutにチェックを入れ、Signature Certificateにslo.certをアップロードします。
- OktaのSAML設定手順にあるメタデータURLを開き/slo/samlで終わるURLをコピーします。
- Salesforceのシングルサインオン設定の編集をクリックし、シングルログアウトを有効にするにチェックを入れ、ID プロバイダのシングルログアウト URLにコピーした/slo/samlで終わるURLを設定し、保存をクリックします。
Salesforceのログイン画面でOktaログインを有効化する
- Salesforceで設定>会社の設定>私のドメインを開き、認証設定の編集クリックします。
- 今回作成した認証サービスにチェックを入れます。
この時にログインフォームにもチェックを入れると下記のようにID/Passwordによるログインと併用することもできます。
プロビジョニング設定
Salesforce設定
- Salesforceの設定>アプリケーション>アプリケーションマネージャへ移動し、新規接続アプリケーションをクリックします。
- 基本情報で接続アプリケーション名、API 参照名、取引先責任者 メールを入力し、API (OAuth 設定の有効化)のチェックを入れます。
- API (OAuth 設定の有効化)を以下のように設定を行い保存をします。
コールバックURLにhttps://system-admin.okta.com/admin/app/generic/oauth20redirectを入力
OAuth 範囲として、APIを使用してユーザデータを管理(api)といつでも要求を実行(efresh_token、offline_access)を追加
Webサーバーフローの秘密が必要にチェックを入れる
更新トークンフローの秘密が必要にチェックを入れる
- 保存後、反映されるまで10分程度待ちます。
- 10分経過後にアプリケーションマネージャの一覧から作成したアプリケーションの右端のメニューから参照をクリックします。
- 表示されるコンシューマ鍵とコンシューマの秘密をそれぞれコピーしておきます。
Okta設定
- OktaのSalesforceアプリケーション設定内のProvisioningでConfigure API Integrationをクリックします。
- Enable API Integrationにチェックを入れ、コピーしておいたコンシューマ鍵とコンシューマの秘密をそれぞれ設定します。
- Authenticate with Salesforce.comをクリックし、アクセス許可を与えます。
- OktaのIntegration画面でエラーが発生していないことを確認してSaveをクリックします。
ハマったポイント
SSO設定でのハマりポイント
OktaからSSOを試してみたところ以下のエラーが表示されました。
原因と対処方法
SalesforceのSandboxではユーザー名がメールアドレスにプラスして.サンドボックス名となることが原因です。今回はmfatestというSandbox名だったため、zzz@abc.com.mfatestという形式で認証を行う必要があります。
対処方法として、OktaのSalesforceアプリケーションのSign Onタブ内のSettingsでApplication username formatをOkta usernameからCustomを選択し、user.email+”.Sandbox名”とします。
これによりAssignmentsでユーザーをアサインする際に自動的にUsernameに.Sandbox名が付与され、Salesforce側のユーザー名と一致しSSOも正常に動作するようになりました。
もちろんこれはSandbox環境の時に必要な対処方法であるため、別途本番環境に対する設定を行う場合は不要です。
プロビジョニング設定でのハマりポイント
検証の初期段階で、プロビジョニング設定時にSalesforceでアクセス許可を正常に行ったにも関わらず以下のようなエラーが発生しました。
原因と対処方法
当初はOktaのSalesforceアプリケーション設定のGeneralでInstance TypeをProductionを選択していたため、プロビジョニング設定でSalesforceへアクセス許可を行った際に本番環境を確認する挙動となっていました。
OktaのSalesforceアプリケーション設定のGeneralでInstance TypeをSandboxを選択し、あらためてアクセス許可を実施することで正常にプロビジョニング設定を終えることができました。
最後に
今回の検証でSalesforceを初めて触ってみましたが多くの設定項目があり、どこから遷移するのだろうかと悩むことが多かったです。
そんな時でも弊社にはSalesforceマスターのBarusu?がいます。今回の検証では多くのインプットを彼から貰うことで無事に進めることができました。あらためて自社の層の厚さを感じられ嬉しかったです。
この記事がSalesforceのSSO設定やプロビジョニング設定がイマイチよくわからんという方の助けになればと思います。
