Identity

ソーシャルサインオンのフロー整理

2021.03.24

概要本記事では、Salesforceの主に外部サイトの構築のログイン認証で使用するソーシャルサインオンを整理します。ソーシャルサインオンではSalesforceがRP(Relying Party)となり、認証/認可はソーシャル(Facebook/Google/Twitter etc)で行います。基本的にはOpenID Connectを用いたシングルサインオンとなるため、内部ユーザというよりExperience Cloudなどの外部ユーザのログインに使用されるケースが多いかと思います。内部ユーザ向けに利用されるSAMLの認証フローについては下記の記事を参考にしてください。 OpenID Connectとは RESTベースで実装されており、クラウド系のサービス、アプリケーションに向いた仕組みである。OpenIDに対応した実装を作るプログラマ視点で見るとSAMLよりも容易に実装を構築できる。先にRPにアクセスするユースケースしかサポートしていないため、ログインポータルを作ることはできない。OpenID ConnectはOAuthの技術をベースにしている。OAuthは厳密にはSSOではなく、権限移譲のためのプロトコルである。 OpenID ConnectやOAuthについて、詳細の流れやフローについては下記の記事を参考にしてください。ソーシャルサインオンの認証フローソーシャルサインオンの認証フローはOpenID Connectを用いており、下記のようなシーケンスとなっております。ソーシャルサインオンの設定 Facebookに認証用のアプリを作成 Facebookの開発者サイトから自分のアカウントにログインしてアプリ作成を行います。https://developers.facebook.com/ アプリIDとapp secretを取得します。認証プロバイダの作成 FacebookをIDPとする認証を行うためにSalesforceの認証プロバイダを作成します。プロバイダタイプは「Facebook」を選択し、取得したアプリID→コンシューマ鍵、app secret→コンシューマの秘密を入力します。登録ハンドラは、一旦[登録ハンドラテンプレートを自動作成]を選択しておきます。登録ハンドラーを更新開発者コンソールから自動生成されたApexを下記のGitHubのサンプルコードで上書きします。なお、プロファイル名やアカウント名などはサンプルなので組織の情報に合わせてアップデートする必要があります。https://github.com/salesforceidentity/IdentityTrail-Module3/blob/master/SimpleFacebookRegistrationHandler.cls 外部サイトへの紐付け Experience Cloudのワークスペース – 管理 – ログイン&登録の設定で先ほど作成した認証プロバイダを有効化します。 FacebookのアプリにリダイレクトURIを登録動作検証外部サイトにアクセスしてログイン画面に表示されているFacebookのアイコンを押下します。 Facebookのログイン画面にリダイレクトされます。 Facebookへのログインが成功すると、Facebookの認可の画面が表示されます。許可するとContactやUserが自動生成されてサイトへログインしている状態となりました。参考ソーシャルサインオンの設定https://trailhead.salesforce.com/ja/content/learn/modules/identity_external/identity_external_social 認証プロバイダhttps://help.salesforce.com/articleView?id=sf.sso_authentication_providers.htm&type=5 登録ハンドラーhttps://developer.salesforce.com/docs/atlas.ja-jp.apexcode.meta/apexcode/apex_auth_plugin.htm

SAML認証フロー整理

2021.03.21

概要本記事ではSAML認証フローを用いてシングルサインオンを実現する流れをSalesforceのプラットフォームでの設定を用いて仕組みを整理します。主な用語の内容は以下の通りになります。 Idp Identity Provider。ユーザーのIDやパスワードなどの認証情報を提供する役割を果たす。 SP Service Provider。IdPに認証を委託し、IdPによる認証情報を信頼してユーザーにサービスを提供する。OpenID Connectの場合には、RP (Relying Party) ともいう。 SAMLとは SAMLは、Security Assertion Markup Languageの略であり、Webサービスベースのシングルサインオンプロトコルである。認証情報のやりとりなどにXMLを利用。企業向けの従来型のソフトウェア製品などで採用されているケースが多い。利用者先にIdpにアクセスするユースケース(Idp Initiated)と、先にSPにアクセスするユースケース(SP Initiated)の両方をサポートしている。 OpenID Connectとの使い分け SAMLはOpenID Connectとは違いIdpとSPが直接通信を行う必要がないという点が一番大きな違いであるため、大体の使い分けは以下の通りになります。 SAML・・・エンタープライズ向け OpenID Connect・・・コンシューマーサービス向け SAMLフロー種類 Idp-Initiated Idp-Initiatedフローは、Idp側が起点となるのでユーザがIdpのログイン画面等にアクセスする処理から始まり、認証を行った後にSAMLレスポンスに含むSAMLアサーションをSPで検証してログイン状態とします。 SP-Initiated SP-Initiatedフローは、SP側が起点となり未ログインであった場合にはIdpへリダイレクトしてIdpで認証を行った後にSAMLレスポンスに含むSAMLアサーションをSPで検証してログイン状態とします。 SalesforceでのSAML SalesforceでのSAML認証フローを用いたシングルサインオンの設定を確認していきます。統合IDを設定するシングルサインオンでログインするSalesforceのユーザに保持する統合IDを設定します。 SSOプロバイダを作成するシングルサインオン設定で『SAMLを有効化』をチェックします。 SAMLシングルサインオン構成を作成します。上記のシングルサインオン設定に対してIDプロバイダから返されるSAMLアサーションのサンプルは以下の通りとなります。 Salesforceのログイン画面へIDPを追加 [私のドメイン]の認証設定で上記のIDPを認証サービスとして選択することで、IDPのログイン画面へリダイレクトさせることができるようになります。参考内部ユーザのシングルサインオンの設定https://trailhead.salesforce.com/ja/content/learn/modules/identity_login/identity_login_sso SAML シングルサインオンを使用するサービスプロバイダとして Salesforce を設定https://help.salesforce.com/articleView?id=sf.sso_saml.htm&type=5 [私のドメイン] ログインページへの ID プロバイダの追加 https://help.salesforce.com/articleView?id=sf.domain_name_login_id_prov.htm&type=5

SalesforceにおけるOAuth2.0/OpenID Connect

Identity

2020.05.20

概要本記事では、業界標準であるOAuth2.0とOpenID Connectの概要を紹介した後に、Salesforceではそれらをどのように実装することができるのかを簡単に記載していきたいと思います。本記事のベースとなるOAuth2.0やOpenID Connectの技術的な事項はこちらの本で学習しました。クライアント、認可サーバー、保護対象リソースのそれぞれについてサンプルのソースコードでどのように動作するかが詳細に記載されており理解するのに非常に役に立ちました。おすすめです。認証・認可とはそれぞれ詳細を説明すると非常に長くなるのですが、あえて一言で言うと下記で表せます。認証通信の相手が誰(何)であるかを確認すること認可とある特定の条件に対して、リソースアクセスの権限を与えること Salesforceにおける認証・認可とは Salesforceで実現可能な認証・認可の仕組みは下記が上げられます。 # 名称概要機能名 1 フォーム認証 Webブラウザでユーザ名とパスワードを入力する最も基本的な認証方式標準ログイン画面 2 2要素認証認証に2つ目の要素を追加することでセキュリティを強化する Salesforce Authenticator 3 SSO 一回の認証で複数のサービスを利用できる仕組みSalesforceは、IdpとSPのどちらになることもできる SAMLシングルサインオン 4 証明書認証 PCもしくはモバイルデバイスに配布されたクライアント証明書でログイン認証を行う証明書認証 5 OAuth/OpenID Connect ←本記事ではこれを解説外部アプリケーションにSalesforceのデータへのアクセスする際にその認可を与える仕組み接続アプリケーション 6 Social Sign on ソーシャルアカウントで認証を行う認証プロバイダ 7 代理認証ユーザの認証を外部サービスで行う外部サービスはSalesforceが指定するWSDLに合わせたインターフェースを実装する必要がある代理認証 OAuth2.0とは概要 OAuth2.0は、業界標準でありRFCに下記のように定義されております。RFC6794(The OAuth 2.0 Authorization Framework)https://tools.ietf.org/html/rfc6749 ‘OAuth 2.0 は, サードパーティーアプリケーションによるHTTPサービスへの限定的なアクセスを可能にする認可フレームワークである. サードパーティーアプリケーションによるアクセス権の取得には, リソースオーナーとHTTPサービスの間で同意のためのインタラクションを伴う場合もあるが, サードパーティーアプリケーション自身が自らの権限においてアクセスを許可する場合もある. 本仕様書はRFC 5849に記載されているOAuth 1.0 プロトコルを廃止し, その代替となるものである.’ 言い換えると、下記のように表せます。リソース所有者の代わりとして対象のリソースへのアクセスを許可するための手段サード・パーティー製のアプリケーションがHTTPサービスへの制限されたアクセス権を取得できるするようにするためのもの OAuthとはシステムを構成しているある要素から別の構成要素にアクセス権を渡すためのものでは、なんのためにOAuthを使用して認可をするかというとサード・パーティ製のアプリケーションにユーザーの ID & パスワードを渡さないとなります。概要イメージ 0. まずユーザであるリソース所有者がクライアントのアプリケーションを使用します。1. クライアントは、保護対象リソースへアクセスするために一旦認可サーバーへリクエストを行います。2. 認可サーバーはリソース所有者との間でユーザ認証および認可を行います。3. 認可サーバーはユーザとの認証・認可が完了しているので、クライアントへアクセストークンを返却します。4. クライアントは、保護対象リソースへアクセストークンを利用してAPIアクセスを行います。各構成要素クライアント・・・ソフトウェアであり、リソース所有者の代わりとして保護対象リソースへのアクセスを行うもの認可サーバー・・・ OAuthの仕組みの中心的な役割を担うHTTPサーバーのこと. リソース所有者にクライアントを認可するための仕組みを提供し、トークンをクライアントに発行するものリソース所有者・・・クライアントにアクセス権を委譲する権限を持つ存在. ソフトウェアでなくユーザー. 保護対象リソース・・・ HTTPサーバーから提供されており、そのリソースにアクセスするにはOAuthのトークンが必要となる. 保護対象リソースは提示されたトークンを検証して、リクエストに応えるかを判定するアクセストークン・・・認可サーバーによってクライアントへ発行され、クライアントに権限が委譲されたことを示すものスコープ・・・保護対象リソースでの権限を表すものであり、クライアントに付与されるアクセス権限を制限するための仕組みリフレッシュトークン・・・新しいアクセストークンを発行するために使用する認可コードフロー(Authrorization Code Grant Type) OAuthのいくつかあるフローの中で最も標準的なフローである認可コードフローは下記のようになります。認可リクエスト/認可レスポンスのイメージ response_type=codeで認可コードフローを指定 codeの値が発行された認可コードトークンリクエスト/トークンレスポンスのイメージ grant_type ・・・ authorization_codeで認可コードフローを指定。その他のフロー # フロー名概要 1 認可コードフロー(Authorization Code Type) 最も標準系のフロー。クライアントが認可コードを経由してアクセストークンを取得する。 2 インプリシットフロー(Implicit Grant Type) JavaScriptアプリケーション等で完全にブラウザ内で動作している場合に使用する。クライアントは認可エンドポイントから直接アクセストークンを取得する。 3 クライアント・クレデンシャルフロー(Client Credentials Grant Type) ユーザに関係なくクライアントアプリへ直接アクセストークンを発行する。 4 リソースオーナー・パスワード・クレデンシャルズフロー(Resource Owner Password Credentials Grant Type) 基本的に非推奨。(アンチパターン)アプリケーション側でID、PWを入力させて、それをトークンエンドポイントへ送り直接アクセストークンを取得する。 5 リフレッシュトークンフロー(Refresh Token Grant Type) リフレッシュトークンを使用して、アクセストークンの再発行を行う。 OpenID Connectとは概要 OpenID Connect Core1.0https://openid.net/connect/ OpenID Connect 1.0 は, OAuth 2.0 プロトコルの上にシンプルなアイデンティティレイヤーを付与したものである. このプロトコルは Client が Authorization Server の認証結果に基づいて End-User のアイデンティティを検証可能にする. また同時に End-User の必要最低限のプロフィール情報を, 相互運用可能かつ RESTful な形で取得することも可能にする. これらをわかりやすく言い換えると下記のように表せます。 OAuth 2.0 ＋ Identity Layer ＝ OpenID Connect Identity Layer ＝ ID Token ＋ UserInfo […]