freedom-man.com

ブログは俺のセーブポイント

Tag: OAuth (page 1 of 2)

カスタム接続アプリケーションハンドラ試してみた

Winter ’16でカスタム接続アプリケーションハンドラなるものがリリースされたので、こちらの機能を試してみました。

この機能は接続アプリケーション(OAuth, SAML)の振る舞いを変更することができます。
具体的には以下の振る舞いを変更することができます。

  • 「管理者が承認したユーザは事前承認済み」のポリシーにおけるauthorize処理
  • refresh tokenによるrefresh処理
  • userinfoやSAMLアサーションに利用されるカスタム属性の動的生成

カスタム接続アプリケーションハンドラ自体はAuth.ConnectedAppPluginクラスを継承して実装することになります。
詳細はこちらを参照→ConnectedAppPlugin Class | Force.com Apex Code Developer’s Guide | Salesforce Developers

Continue reading

oauth2-server-phpでOAuth2.0 Providerを実装してみた。

OAuth2.0 Providerを実装したく、OSSを色々と巡ってみて

bshaffer/oauth2-server-phpが使いやすそうだったので触ってみましたー。

 

今回はAuthorization Code Grantのフローを実装してみました。

構成は以下のとおり。

  • Platform: heroku
  • Database: postgres(Heroku Postgres)
  • Language: php(5.6.11)
  • Web server: Apache(2.4.10)

 

参考URL→Step-By-Step Walkthrough

インストール

composer.jsonにbshaffer/oauth2-server-phpを追加

で、インストール。

DBのセットアップ

Postgresで以下のSQLを実行します。

クライアントID、シークレットは以下のようなSQLでレコードを突っ込んでおきます。

ユーザも作成しておきます。

passwordはsha1のハッシュ値を入力します。

厳密に言うとoauth_usersテーブル内に保持する必要は無いのですが、

Resource Owner Password Credentials Grantを実装する場合は、参照先がoauth_usersなので

クレデンシャルのリポジトリはoauth_usersで統一しておいた方が良い気がします。

画面・処理の作成

アプリケーションルート直下にserver.phpを以下の内容で作成します。

DB(Storageクラス)とスコープ以外は大体同じコードになると思います。

 

token.phpはこんな感じ

 

authorze.phpはこんな感じ

「○○へのアクセスを許可します」的な認可のスコープに応じたメッセージを出したい場合は

$server->getScopeUtil()->getScopeFromRequest($request) でスコープのリストを取得して

メッセージを表示するようにします。

 

APIはこんな感じで作ります(今回はapi.phpで作成)

スコープに応じたアクセス許可をする場合は、

$server->verifyResourceRequestの$scopeRequiredパラメータに必須のスコープをセットします。

 

最後にindex.phpにログインフォーム/処理を作ります。

herokuへデプロイ

Procfileは以下のとおり

動作確認

SalesforceのNamed Credentialsで動作確認をしてみます。

認証プロバイダはこんな感じ

oauth2-server-php-sfprovider

postgresのアプリケーションのリダイレクトURIを認証プロバイダのコールバックURLに変更します。

指定ログイン情報はこんな感じ

oauth2-server-php-sf-namedcredential

認証/認可画面はこんな感じに表示されます。

oauth2-server-php-login

oauth2-server-php-authorize

あとはApexで以下のコードを書いて実行してjsonが返ってくればOK。

 

force.comポータルでOAuth2.0

以前の記事でforce.comでREST APIを使用する際のドメイン名に関して取り上げたけど

ポータルへのOAuth認証(Sites利用)は

普通のSalesforceユーザへのOAuthの設定方法よりやや面倒な感じになる。

ということで、今回はポータル+Sites+OAuthについて書いてみる。

 

【ポータルOAuthの事前準備】

ポータルユーザに対してREST APIを利用したい場合は、対象ポータルに紐付けたSitesを設定する必要がある

※ポータルユーザに対してREST APIのOAuthリクエストをする際のドメインは、Sitesのドメインになる。

 

【ポータルOAuthの仕様・注意点】

1. SitesドメインのOAuthエンドポイントに対してAuthorizationCodeをリクエストするときに

ポータルユーザのセッションIDが切れていた場合は401のエラーページに遷移するので

当ページでログイン処理を行う必要がある。

2. 401のエラーページではSite.Loginメソッドを使ってセッションを発行し

return値(PageReference)をクライアントに返す必要がある。

3. 2のreturn値によってfrontdoor.jspにリダイレクトされることで

セッションIDがCookieにセットされ、OAuthのリダイレクトURLに遷移する。

※2-3の詳細はこの記事を参照。

 

401のエラーページっていうのはSitesの設定の以下の部分。

SitesErrorPage

 

普通のSalesforceユーザに対するOAuth認証と異なるのは1-2の工程。

Sitesを使ってポータルユーザへのOAuthを行う場合には

401のエラーページのVF画面でSite.Loginメソッドを使って認証させる必要があります。

逆に、普通のSalesforceユーザではOAuthログイン画面の自由なカスタマイズが出来ないのに対して

ポータルユーザへのログインはフロントにSitesを利用しているため自由なカスタマイズが出来るということです。

 

また、注意しておかないといけない点としては

認証ページはVF画面(UnAuthorized)を使用できるので自由にカスタマイズできるが

認可の画面はカスタマイズできず、以下のような固定画面になること。

OAuthLoginPage

 

ポータル案件ではデザイン性が要求されるため

カスタマイズできない画面があるというのは、十分留意しておく必要があります。

 

コミュニティはここらへんどうなんだろう…?

JanrainとSalesforce連携してみる

前回説明したJanrain。

これ、SalesforceとSSOできちゃうみたいです。

 

ということで今回はSalesforceとソーシャルサインオン連携してみる回です。

 

認証プロバイダ作るあたりはgoogle, facebook, salesforceでSSOしたときと同じなので

こちらも合わせてご参考ください!

 

1. Janrainアプリのホワイトリストにsalesforceのドメインを追加

helpにはsalesforce.comを追加って書いてありますが

これじゃダメで、login.salesforce.com(あるいは*.salesforce.com)とSitesのドメインを指定してあげます。

JanrainWhiteListExample

 

ホワイトリストの設定が間違っているとこんな感じのエラーが出ます。

login.salesforce.comが設定されていない場合↓

JanrainWhiteListError1

 

Sitesのドメインが設定されていない場合↓

JanrainWhiteListError2

 

 

何気にここが一番のハマりどころでした…。

 

2. 認証プロバイダの登録

セキュリティのコントロール>認証プロバイダから新規に認証プロバイダを作成する。

プロバイダタイプをJanrainにして、コンシューマの秘密にJanrainのappKeyを設定。

 

で、こんな感じになる↓

JanrainIdentityProvider

 

他の認証プロバイダと違ってflowtype=xxxというパラメータが付与されています。

 

3. Sitesにログインページ(VF)を作成

こんな感じ↓

 

flowtype={!$CurrentPage.parameters.type}と、flowtypeパラメータを動的にしたので

https://hoge.force.com/Janrain?type=link でユーザ紐付け

https://hoge.force.com/Janrain?type=sso でSSO連携

をするようにしてます。

 

あとはこのVFをSitesに公開してSignInリンクを押してソーシャルサインオンできちゃう感じです。

 

Janrainは色んなWebサービスに対する認証連携のハブとなるサービスなので

OpenID Connect対応サービス, facebook, salesforce以外を認証プロバイダにしたい場合は

利用価値がありそうです。

 

ただし、無料のbasicプランだとユーザの登録上限が年間2500ユーザらしいのでその点は注意。

とは言え、Salesforce環境で2500ユーザを越えるところって滅多に見ない気がするけど…。

force.com REST APIのOAuthエンドポイント

foce.comのREST APIではOAuth2.0を利用することができるが、

Salesforce環境やユーザによってOAuthのエンドポイントが異なっていたのでメモる。

 

基本的には認可のエンドポイントは

https://[domain]/services/oauth2/authorize

トークン発行のエンドポイントは

https://[domain]/services/oauth2/token

となっており、[domain]の部分がSalesforce環境やログインユーザによって変わってくる感じ。

 

1. 環境によるエンドポイントの違い

■Developer環境・本番環境

→login.salesforce.com

 

■Sandbox環境

→test.salesforce.com

 

■私のドメイン設定時

→私のドメインの値。

上記の環境によるドメイン値も利用できるが、

「https://login.salesforce.comからのログインを防止」にチェックがついていると

ログインされていない状態の場合は、認証画面でログインできないので

素直に私のドメインをエンドポイントにした方が良い。

mydomain

 

2. ポータル・コミュニティユーザの場合

■ポータル

→ポータルに紐付けたSitesを設定し、そのSitesのドメイン名をエンドポイントにする。

基本的にポータルのログイン画面は

https://[domain]/secur/login_portal.jsp?orgId=[orgId]&portalId=[portalId]

の形式になっており、通常のSalesforceのログイン画面ではログインできないため、

Sitesのドメインを介してログインする方式。

 

詳細はこちらから。

ちなみにSOAP APIではorganizationIdやportalIdを設定可能。

 

■コミュニティ

→コミュニティで設定したドメイン名。

こちらはポータルと違ってドメイン名を設定が必須なので、Sitesを使う必要はない。

 

ポータルのSites設定方式は面倒なので、出来れば新機能のコミュニティに寄せたい感じ。

そもそも新規の環境ではコミュニティ使えないはずだし。

Older posts

© 2017 freedom-man.com

Theme by Anders NorenUp ↑