Salesforce 認定 Identity and Access Management デザイナー の試験勉強をしたときのメモ
※Winter '19 の時のメモです
Integration and Access Management ということで、IAM とも略されたりすることもあるようです。 まだ受けてませんが、 (2019/03/20 に無事合格しました) 私の中では最難関の試験でございます。試験勉強はじめた時の私は、「OAuth？よくわからんけど認証系のやつやろ？」くらいの前提知識で、認証と認可の違いすらもよくわかっていなかった状態。。。なので、ここでは初歩の初歩から、勉強した過程でまとめた記録を残しています。 https://gyazo.com/018bd8f48481260819c516e3d37a63d1
まずは受験ガイド
とにかく読み込むやつ
基本的な勉強法はここを読み込むことです。100回くらい読みます。
リンク集
あの情報はどこに書いてあったんだっけ？っと、記憶喪失になることが多かったので、リンクは全部記録しています。参考にさせて頂いた Web ページを列挙します。
いつもお世話になってる海外ブログ
私が書く文章よりもとても良くまとまってるし、試験範囲も網羅できてるし、100回くらい読みました。
いつもありがとうございます。
Trailhead
これを最初にやろう。
コミュニティを作ってセルフ登録ページの設定したり、ソーシャルサインオンをしたり、ソーシャルサインオンのための RegistrationHandler をいじったりします。
Facebook でソーシャルサインオンしてるところは、Facebook を IdP とする SP-Initiated の SSO のことだ、ってことを意識して読むとイメージが掴みやすいかもです。
とても良いサンプルが載ってるモジュールだと思うのですが、難易度が高いです。特に Hands-on Challenge はハマる人が続出してるから (developers forums 談) 読むだけにしといた方が良いかもです。何故かと言うと、モジュール中の github のコードがユーザロケールに超依存したものになってるので、日本人がやる場合には開発者コンソール開いてデバッグログみながらエラーを修正していく必要があるかもなのです。
これはやらなくても良いかもです。OAuth 認証を行う Heroku アプリが出てきます。実装が気になったので、Trailhead 中で紹介されている Heroku App の ソースも読みました。 シングルサインオン
テラスカイ様がまとめてくださったわかりやすい記事です。
ID プロバイダ (IdP)、サービスプロバイダ (SP)、IdP-Initiated、SP-Initiated など、難しい用語がたくさんでてきます。
基本的な概念なので、自分の言葉でもまとめてみます。(こういうことが大事だと勝手に思ってます)
Salesforce は IdP にもなりえるし、SP にもなりえます。そして認証のフローも、IdP を起点とするのか、SP を起点とするのかで2種類あります。例えば以下のような感じです。
IdP-Initiated：認証するのは Salesforce。Salesforce にログイン後、リンククリックとかで他アプリへシングルサインオンする。 SP-Initiated ：認証するのは認証サーバ。Salesforce にログインを試みると、認証サーバにリダイレクトされ、認証が行われる。 記事中にはジャストインタイムユーザプロビジョニングという用語も出ています。海外ブログ等では Just In Time Provisioning ということで、JIT という記載をしているのも見かけました。日本ではプロビって略してるのをよく聞きますが、私のまわりだけかもしれません。。笑 個人的には、IAM の試験は SAML と OAuth をどれだけ理解できているかがキモになると思ってます。 Qiita
SAML とはなんぞや、OAuth とはなんぞや、というところから調べたので、まずは Qiita の記事を読みあさりました。
基本として、サムルは認証、おーおーっすは認可の仕組み
OAuth
OAuth について、上の方に色々なリンクを貼りましたが、これらの記事は一般的な OAuth の仕組みの説明になっています。なので、じゃあ Salesforce だとどうなの？ってのがイマイチわからなかったんですよね。以下は私なりの解釈を書いていきますので、間違っていたらご指摘いただければ幸いです。。。
OAuth にはいくつか種類があります。Salesforce 上での実装も、もちろんたくさん種類があります。。。下記は全部 Salesforce 公式ヘルプへのリンクです。
OAuth 2.0 については内容をよく読んで、どんなときにどんなフローが使われるのか、全部覚えた方が良いと思います。
OAuth 2.0 Web サーバ認証フロー
公式ヘルプでは以下のように記載されてます。
Web サーバフローでの重要な点は、サーバがコンシューマの秘密を保護できる必要があるということです。
うーん、そもそもコンシューマの秘密ってのはなんなんだ？パスワード？
どのフローでもよく使うのですが、重要な点は設定の中でまず Salesforce の接続アプリケーション定義を作成する ということです。接続アプリケーションは、設定 > アプリケーション > アプリケーションマネージャ > 新規接続アプリケーション から作成することができます。接続アプリケーションを作成すると、コンシューマ鍵、コンシューマの秘密 の2つが発行されます。ここで冒頭のコンシューマの秘密が出てきましたね。これを Web サーバ側に事前に渡して設定してやるフローが、Web サーバ認証フローです。サーバは鍵と秘密の両方を持っている、すなわち Web サーバは信頼できるサーバである というのが前提としてあるフローということです。
具体的なフローの流れはヘルプを見てください。。。笑
あと、以下は REST API のヘルプですけど、Web サーバ認証フローの設定例が載っていているのでイメージをつかみやすいです。ご参考までに。
実際に試してみました。
OAuth 2.0 ユーザエージェントフロー
コンシューマの秘密を保持できない OAuth フロー。いろんなとこに配布するクライアントアプリとかで実装されるやつっていうイメージ。クライアントを盲目的に信頼できない場合に使うフローです。変なアプリを認可しちゃって Twitter 乗っ取られる事件とかあったけど、これのことなのかな。(わからん) ←これは嘘でした。よく Twitter にある「許可しますか」的な画面がでるやつは Web サーバ認証フローです。ユーザエージェントフローにその画面は出ません。Web サーバ認証フローであるが故に、アクセストークンがよくわからないサーバに保存されてしまい、それをつかって Twitter を乗っ取ることができる、という仕組みみたいですね。
OAuth 2.0 SAML アサーションフロー
SAML での認証。
Salesforce には SSO を設定していて IdP でログインしているようにしているよ。
だから認証は IdP 側でやってほしいんだけど、Salesforce の OAuth を利用したいんだ、って時に使うフロー
OAuth 2.0 JWT べアラートークンフロー
JWT の読み方は jot (ジョット)。ベアラー (Bearer) = 運ぶ人。最初は熊のことかと思ってました 笑。運搬人のことです。
ちなみに、ネットワーク屋さんは伝送速度のことを「ベアラ速度」と言ったりするらしいです。余談ですね。
利点としては認証認可だの画面が表示されないことです。なので、ETL 等、外部ツールから自動連携させる時等によく利用されます。また、このフローではコンシューマの秘密は利用せず、公開鍵 (Salesforce 側)、秘密鍵 (クライアント側) を利用します。
これについては検証も兼ねて実装してみました。下記記事にまとめています。
実際に試してみました。
OAuth 2.0 更新トークンフロー
OAuth では認可の証としてアクセストークンが発行されますが、アクセストークンには有効期限がありますので、再度アクセストークンを取得する必要があります。その際に利用するフローです。リフレッシュトークンってやつですね。Web サーバ認証フローや、ユーザエージェントフローで必要となります。SAML とか JWT のフローでは不要です。 実際に試してみました。
OAuth 2.0 デバイス認証フロー
IoT のデバイスとか、認証が難しいときに別の高度なデバイスに認証をやってもらうフローです (って書いてあるけど、高度なデバイスってのは普通にPCとかスマホとかだと思う) 。JWT べアラートークンフローでもいいじゃんって思いますが、たとえば複数ユーザにインタラクティブに認証させたいとかそういうときに使うんじゃないかな。Salesforce Authenticator とかはこれなんじゃないかな、わからんぞ。
OAuth 2.0 ユーザ名パスワードフロー
コンシューマにすでにユーザのログイン情報がある場合、ユーザ名パスワード認証フローを使用して認証します。
らしいです。クライアント端末にパスワード(平文？) がある・・・どんな状態なんだろう (セキュリティがヤバそう)。
設定ファイルとかにパスワード埋め込んでる場合とかですかね？OAuth を利用するメリットの1つは、パスワード等のクリデンシャル情報を保持しなくてもよいというものです。なのにそれを使うというのはアウトローな使い方だと思うので、試験でもあまり問われないだろうと予想してあんま調べてないです。 ここ の末尾には、テスト用にセッション ID が必要な時にはこのフローを使うという記述がありますね。 実際に試してみました。
接続アプリケーション
上にも書きましたが、OAuth を利用する際には接続アプリケーションを設定することが多いです。
下の画面に書いてある内容は全部調べておいた方が良いですね。
たとえば、「選択した OAuth の範囲」に項目ではどのような内容が許可されるのか、とか。
https://gyazo.com/e6635ca9d8f02c1e43d53fcf0c81e911
セッションセキュリティレベル
他にも、試験範囲を勉強するまでまったく知らなかった機能をメモとして残しておきます。セッション毎にセキュリティレベルを管理することができます。どういうことかというと、たとえば同じプロファイルでも、ログインの仕方によりセキュリティレベルを変えることのできる機能です。セキュリティレベルには、標準と高保証の2つがあります。
セキュリティ > セッションの管理
https://gyazo.com/5e1e45b98959844da3bfa61ad43ff1ad
各操作に対するセキュリティレベルは、以下から設定します。たとえば、標準のセキュリティレベルでログインした際、高保証な操作が必要となった場合、再度認証の画面へと飛ばされます。
ID > ID 検証
https://gyazo.com/9d87123cf4f5302769e488216286461a