※この内容は2021/12時点のものです。
※このChallengeにはセールスフォース・ドットコム社による解説があります。
getInstance メソッドを使用してカスタムメタデータの情報を返すように書き換えてください。※この内容は2021/12時点のものです。
※このChallengeにはセールスフォース・ドットコム社による解説があります。
Salesforceは通常ログイン画面でユーザ名・パスワードを入力してログインしますが、SSOログインも利用可能です。
また、ログイン方法をSSOのみに制限する方法もヘルプで公開しています。
Salesforce Help: SSO を使用したログインをユーザに要求
このヘルプの内容によると、ログイン方法をSSOのみに制限するには以下3点の設定が必要とのことです。
これを見たとき、こんな疑問を浮かべました。
「組織全体に影響するシングルサインオン設定でSalesforce ログイン情報を使用したログインを無効化して、ユーザに [シングルサインオンの有効] 権限を与える…。
これ [シングルサインオンの有効] 権限与えないとSalesforceにログインできなくなるのでは？」
ということで、検証してみました。
まず、SSOログインが可能な環境を作成し、シングルサインオン設定にて [Salesforce ログイン情報を使用したログインを無効化] を有効にします。
その時の動作は以下の通りです。
次にユーザプロファイルにて、 [Salesforce ログイン情報を使用したログインを無効化] を有効にした際に表示される [シングルサインオンの有効] 権限を付与します。
その時の動作は以下の通りです。
なお、 [シングルサインオンの有効] 権限を付与した場合APIログインもSSOを介さないとログインできなくなります。（ユーザ名・パスワードでのログインだと「このシングルサインオンゲートウェイ URL は無効です」エラー）
[Salesforce ログイン情報を使用したログインを無効化] の名前だけ聞くとこの設定を有効にした時点で組織全体がSSOログイン以外無効化するように見えますが、実際はSSOログインに制限するためのユーザ権限である [シングルサインオンの有効] 権限を表示するためのものでした。
また、 [シングルサインオンの有効] 権限の名前だけだと「SSOログインができるようになるために必要な権限」と思われますが、実際には「SSOログインに限定するための権限」でした。
[シングルサインオンの有効] 権限の英語名は "Is Single Sign-On Enabled" ですので、日本語訳としては合っています。
ただ、（もう少し実際の動作に沿った権限名にしてほしかったなぁ…）と思った一件でした。
MFA FAQでは「システム管理者へのSSOログイン有効化はお勧めしません」とされていますが、仮にSSOを使用する場合、 [シングルサインオンの有効] 権限によるSSOログイン限定をシステム管理者のみ外す、という方法はありかな、と思いました。
Salesforce Helpの中に、英語版のみではありますが制限拡張、機能有効化に関するヘルプ一覧がまとめられたページを発見しました。
Salesforce Help: Common Feature Activation and Limit Change requests
以下、上記ヘルプのリストを依頼方法に沿ってリスト化した制限拡張、機能有効化の一覧となります。
（日本語版が存在するヘルプは日本語版を、存在しないヘルプは英語版が表示されるようリンクを設定しています。）
上記制限拡張、機能有効化を依頼する際、Salesforceサポートは以下の情報を要求します。
その他、申請内容によっては別途必要事項を記載する必要がありますので、事前に上記ヘルプを参照することをお勧めします。
*1:Winter '15 より前に Salesforce の使用を開始した場合はサポート問い合わせ
2021/10/4に、CERT/CCよりSalesforce DX CLIについてアクセス制限不備の問題が指摘されました。
これに対し、Salesforceでは Salesforce ヘルプ: Salesforce Developer Experience Command Line Interface の設定 を公開しましたが、具体性がなく何が起きているのか分からない内容となっています。
ここでは、実際にどのような操作が問題なのか、また対応策について書いていきます。
筆者は普段Salesforce DX CLIを使っておらず、一部憶測を含む部分があります。
本投稿の内容を試した際など、掲載内容からいかなる損失や損害などの被害が発生したとしても、当ブログでは責任を負いません。（サイトポリシーの免責事項もお読みください。）
Salesforce DX CLI には、登録した組織・ユーザにコマンド1つでログインできる機能があるのですが、そのコマンドを実行した際にそのユーザとして組織にログインできるURLが出力されます。
これが今回問題となった機能と思われます。
sfdx force:auth:web:login を実行し、ブラウザ画面からSalesforceにログインする。これにより Salesforce DX CLI 側に組織、ユーザ情報が登録される。sfdx force:org:open を実行する。これにより sfdx force:auth:web:login コマンドでログインしたユーザと同じユーザでログインした状態でブラウザが起動すると同時に、そのユーザとして組織にログインできるURLが出力される。実際のコマンド実行と出力内容の例です。
> sfdx force:auth:web:login -a test # このコマンド実行後、Salesforceログイン画面が表示された状態でブラウザが起動する。 # この画面でログインすることで Salesforce DX CLI 側に組織、ユーザ情報が登録される。 > sfdx force:org:list === Orgs ALIAS USERNAME ORG ID CONNECTED STATUS ───── ─────────────────── ────────────────── ───────────────────── test test@sampleorg.com 00DxxYYYYYzzzzzAAA Connected # force:auth:web:login でログインした情報が表示される > sfdx force:org:open -u test WARNING: This command will expose sensitive information that allows for subsequent activity using your current authenticated session. Sharing this information is equivalent to logging someone in under the current credential, resulting in unintended access and escalation of privilege. For additional information, please review the authorization section of the https://developer.salesforce.com/docs/atlas.en-us.234.0.sfdx_dev.meta/sfdx_dev/sfdx_dev_auth_web_flow.htm Access org 00DxxYYYYYzzzzzAAA as user test@sampleorg.com with the following URL: https://mysampledomain.my.salesforce.com/secur/frontdoor.jsp?sid=00DxxYYYYYzzzzz!heersgKJolaf0kq3rLMODASA... Waiting to resolve the Lightning Experience-enabled custom domain...... done
上記コマンドの https://mysampledomain.my.salesforce.com/secur/frontdoor.jsp?sid=00DxxYYYYYzzzzz!heersgKJolaf0kq3rLMODASA... が「そのユーザとして組織にログインできるURL」です。
上記URLの sid はセッションIDを指すと思われます。つまりこのURLを悪用すればセッションハイジャックができてしまうということです。
Salesforce DX CLI では、スクラッチ組織という開発者が開発のために作ることができる組織があります。（Developer Edition組織とは別です。）
この「スクラッチ組織を使って開発する」ことを考えたときに、複数人でチームとして開発しており、開発の内容をチーム内で確認してもらいたいときは「スクラッチ組織に開発者全員のユーザアカウントを作成してアクセスしてもらう」よりも「システム管理者としてログインできるURLを発行してそれをチーム内に連携する」方が便利です。
（「スクラッチ組織を作成→その組織にログイン」の流れが force:org:create → force:org:open とコマンドで完結し、ログイン画面を介さないため「ユーザ名とパスワードを連携する」という方法も不便になってしまう。）
よって、Salesforceとしてはこの機能は開発用に用意したものであり、本番環境はセッションハイジャックを防ぐためにセッション設定を用意しているのでそれを適用するように、というのが見解だと思われます。
発行されたURLはログイン済のセッションを用いているため、ユーザ名、パスワードはもちろん多要素認証を必須にしていたとしても多要素認証の情報なしにログイン後の画面にアクセスできてしまいます。
さらに、ログイン履歴にもこのURLを用いたアクセスは記録されません。（アクセス後にレコードを参照すると、「最近参照したレコード」として記録はされます。）
発行されたURLからの外部アクセスを防ぐためには「セッションの設定」にて防止用の設定を導入する必要があります。 具体的には以下2点です。
これはログイン時のIPアドレスとログイン後のIPアドレスが変わった場合にそのセッションを切断し、再度ログインを要求する機能です。
これにより、 Salesforce DX CLI で発行されたIDに外部からアクセスしようとしてもログイン画面に戻されます。
ただし、「ログイン時の IP アドレスとセッションをロックする」を有効にした後のログインが対象となります。有効にする前にログインした際のセッションはこの機能の制限を受けません。
これを有効にするとSalesforceアクセス後に自分の端末のIPアドレスが変わるとログイン画面に戻されることになります。（ノートPCやスマートフォンでは影響があるでしょう。）
また、Salesforceヘルプ: セッションセキュリティ設定の変更 にも「この設定は、さまざまなアプリケーションやモバイルデバイスの機能を妨げる可能性があります。」という注意書きがありますので、安易な設定はお勧めできません。
これはログイン IP アドレスの制限が設定されているユーザにてログイン後にIPアドレスがログイン IP アドレスの制限の範囲外になった場合、エラーとする機能です。
これも同様に、Salesforce DX CLI で発行されたIDにログイン IP アドレスの制限範囲外となる外部からアクセスしようとしてもエラーになりますが、Salesforceアクセス後に自分の端末のIPアドレスがログイン IP アドレスの制限範囲外になった場合もエラーになります。（ノートPCやスマートフォンで、VPN使用時にVPNが切断された場合などが該当するでしょう。）
ここでは2つの設定を紹介しましたが、いずれにも言える点は「たとえ有効にしたとしてもセッションハイジャックを完全に防ぐことはできない」という点です。
具体的にはどちらの設定もログイン後にIPアドレスが変わったことをトリガとしてエラーとするため、「社内で Salesforce DX CLI により発行されたURLを盗み見てアクセスすればセッションハイジャックできる」といった内部犯行を防げません。（社内のPCに対しグローバルIPアドレスを個別に割り振っているのであればこのような内部犯行は防げますが、そのような会社はごく少数でしょう。）
よって、セッションハイジャックを完全に防ぐ方法として「本番環境では force:org:open を使わない」を提案します。
そもそも force:org:open はスクラッチ組織のためにあるものだと考えれば、ユーザ名、パスワードを入力すればログインできる本番組織には不要とも言えます。
コマンド1つでログイン画面が表示できるのは便利ではありますが、セキュリティを考慮すると本番環境では使わない方がよいと考えます。
今回の問題はゲストユーザ問題と同様、責任共有モデルが大きく関わってきます。
つまり「Salesforceはセッションハイジャック防止用の設定を用意しているので、ユーザの責任で導入してください。」というものです。
しかし先述の通りアクセス元IPアドレスが変わらない状況にてセッションハイジャックを防ぐ機能がSalesforceにない現状では、片手落ちの印象も受けます。
本件について記載されたヘルプでは「今後、機能拡張があった場合は、この記事を更新します。」とのことですので、何らかの機能拡張があるか注目したいと思います。
今年もDreamforceが終わりました。
Twitterを見てると、今年はワークフローとプロセスビルダーからフローに乗り換えに関する話題で盛り上がりましたね。
約1年後にはワークフローとプロセスビルダーの新規作成を禁止されるとなると結構な重要事項ですが、今回のテーマはそれではありません。
True to the Core オンデマンド録画の25分ごろからその話題になるのですが、ここでスピーカーのPatrick Stokes氏はタイムライン説明の際に "Spring ‘22" といった形ではなく ”Two thirty-six”, "Two thirty-eight", "Two fourty" と話しています。
しかし紹介したブログには、 "Spring ‘22", "Summer'22", "Winter'23" と従来のバージョン名で記載されています。
これはどういったことなのでしょうか。
実はSalesforceのリリースバージョンには、"Winter'22"のような我々がよく知る「季節+年」の表記以外に数字のバージョン番号も設定されています。
それはSalesforceリリースノートのURLを見れば分かります。
このように、releaseURLパラメータがSummer'21では232、Winter'22では234と2増えています。
このルールは今後のバージョンでも同様ですので、
となります。
Patrick Stokes氏はバージョンをこの番号で説明しており、それをブログ著者が「季節+年」の表記に書き換えたんですね。
通常、Salesforceのバージョンは「季節+年」表記で表されており、一般ユーザがバージョン番号を聞くことは滅多にありません。*1
少なくともDreamforceのこのセッションは一般向けではなかった、ということでしょうか。
releaseURLパラメータはメジャーリリースごとに2増える、と覚えておくと先述のリリースノートのURLパラメータ書き換えだけで希望のリリースノートを見つけることができたりするなど*2、いいことがあるかもしれません。
※この内容は2021/9時点のものです。
※筆者注：Challenge前に組織設定にて言語のデフォルト値を「英語」にする必要があります。
*1:設定項目の表示には組織設定にて言語のデフォルト値を「英語」にする必要があります
Salesforce Platform API バージョンが古いものについて、以下のように順次サポート終了、アクセス不可が予定されています。
こうなると自分の組織に古いAPI バージョンのアクセスがないか気になるところですが、これを確認する方法は現状EventLogしかありません。
しかし、イベントログの開発者ドキュメントには以下の記載があります。
安全でない外部アセットイベント、ログインイベント、ログアウトイベントは、サポートされている Salesforce エディションで追加費用なしで使用できます。残りのイベントタイプを購入するには、Salesforce にお問い合わせください。
APIアクセスイベントは上記でいう「残りのイベントタイプ」になります。 つまりEvent Monitoringライセンスを購入しないと古いAPI バージョンのアクセスがあるかないか分からないのです。
しかし、それでは困るという顧客の声があったのでしょう。
Summer'21リリースにてAPI 合計使用量イベントを使用した API バージョンの使用の追跡というリリースが行われました。
このイベントは、バージョン 30.0 までの SOAP、Bulk v1、および REST API 要求へのコールを記録します。データは 24 時間保持されます。
(中略)
API 合計使用量イベントは、すべての顧客が無料で使用できます。
これにより、追加費用なしでも廃止対象APIバージョンのアクセスを確認することができるようになりました。
実際にAPI 合計使用量イベント(ApiTotalUsage)が取得できるか試してみました。
今回はWorkbenchでアクセスします。
/services/data/v20.0/sobjects/account/describe で指定して[Execute]をクリック
Workbenchアクセス後、1日待って以下作業を行います。
実際の結果はこうなりました。（CSVから一部抜粋）
| EVENT_TYPE | API_FAMILY | API_VERSION | API_RESOURCE | HTTP_METHOD |
|---|---|---|---|---|
| ApiTotalUsage | REST | 20 | /v20.0/sobjects/account/describe | GET |
ちゃんとバージョン20のAPIアクセスが記録されていますね。
注意点として追加費用なしの場合、イベントログは1日しか残らない点が挙げられます。
つまりアクセスの有無を確認するには毎日取得しなければならないので、実際に取得を検討される方はご注意ください。
Salesforceユーザライセンスのうち、比較的安価な Lightning Platform Starter ライセンスと Lightning Platform Plus ライセンス。
この2つのライセンスは、ヘルプにてケースオブジェクトにアクセス可能なことが明言されています。
しかし、Lightning Platform Starter, Plus ユーザライセンスを購入するとSalesforce組織上では Salesforce Platform ユーザライセンスとして有効化されますが、 Salesforce Platform ユーザライセンスではケースオブジェクトにアクセスできません。 権限セットを割り当てようとしても以下のようにエラーになります。
実はヘルプの冒頭に
「Lightning Platform Starter と Lightning Platform Plus のどちらにも Salesforce Platform ライセンスと Company Communities 権限セットライセンスが含まれます。次の表は、Salesforce Platform ライセンスが付与され、Company Communities 権限セットライセンスが割り当てられているユーザが使用できる機能を示します。」
という文言がある通り、 ケースオブジェクトにアクセスさせるには Company Communities 権限セットライセンスをユーザに付与する必要があります。
Company Communities 権限セットライセンスは、Salesforce組織上では「Company Community for Force.com」権限セットライセンスとして有効化されます。
Company Communities 権限セットライセンスをユーザに付与する具体的な手順は以下になります。
上記手順で作成した権限セットは、Salesforce Platformユーザライセンス以外のユーザにも割り当てられます。
つまり、SalesforceユーザライセンスのユーザにCompany Communities 権限セットライセンスを割り当てることもできますが、これはCompany Communities 権限セットライセンスを無駄にする行為です。（Salesforceユーザライセンスは単体でケースアクセス可能なため）
Company Communities 権限セットライセンスを使った権限セットの割り当てはSalesforce Platformユーザに限定するようにしましょう。
Salesforce ヘルプ: Grant users with Salesforce Platform License access to Case object
Trailblazer CommunityがTrailheadと合流したため、Known IssueとIdeaExchangeはページの形式が変わりました。
https://trailblazer.salesforce.com/ideaSearchtrailblazer.salesforce.com
さらにKnown IssueとIdeaExchangeの検索結果画面は、Salesforce Help画面に統合されました。
しかし、Salesforce Help側の検索画面…、個人的な思いですがなんか使いにくいんですよね…。
例えば、「lightning report」でIdeaExchangeを検索した場合の結果を比較しましょう。
旧画面の方では「関連する投稿→ポイント数降順」のソートがかかっているように見えます。
結果、検索に関連する投稿のうち、よりポイント数が多い＝他ユーザの共感が多い投稿が上位になります。
一方、新画面の方はステータスがMerged(=0ポイント)の投稿が最上位となっており、完全に検索キーワードとの関連度のみでソートしているように見えます。
これが致命的に悪いというつもりはありませんが、個人的には旧画面の方が好みなのです。
かといって、現時点ではKnown IssueとIdeaExchangeページの検索窓にキーワードを入力すると強制的にSalesforce Help画面に遷移するので、旧画面の検索結果は表示できません。
そこで、URLパラメータを使い、以下のようにURLに検索キーワードを直打ちします。
https://trailblazers.salesforce.com/issues_index?keywords=<検索キーワード>
https://trailblazers.salesforce.com/ideasearch?keywords=<検索キーワード>
これで旧画面の検索結果ページを引き続き表示させることができます。
私のような旧画面の検索結果ページが好みだった方にお使いいただければ幸いです。
