9/18@大阪、9/20@東京で開催された「ID&IT Management Conference 2013」が、無事終了しました。
公式サイト
http://nosurrender.jp/idit2013/
先日投稿した通り、私は JNSA の IdM-WG のメンバでのパネルディスカッションを担当しました。
時間が限られてたのでなかなか多くは伝えられませんでしたが、とりあえず無事に終了して良かったかな、、と思っています。
当日使った資料を公開しましたので、よろしければご覧ください。
後、一番のジェネラルセッションの資料もExgen江川社長が公開していらっしゃいましたので、紹介しておきます。
今後エンタープライズがどういう方向に進んでいくのか？についてわかりやすく解説されているので、ぜひご覧ください。
最後に、OpenID Foundation Japanのエヴァンジェリスト @nov が togetter で当日のまとめを作っているので参加できなかった方はこちらを見ると雰囲気がつかめると思います。
ID & IT 2013 - Osaka #idit2013
http://togetter.com/li/565725
2013年9月21日土曜日
2013年9月14日土曜日
[FIM2010]gacutil.exeを使わずにカスタムワークフローをGACへ取り込む方法
Forefront Identity Manager（FIM 2010）のカスタマイズのポイントを大きく分けると以下の4つになります。
これまでこのブログで紹介したことがあるのは3番目のUIのカスタマイズと、4番目の管理エージェントの作成方法でした。
ユーザインターフェイス（UI)
[FIM2010] ポータルのナビゲーションバーをカスタマイズする
http://idmlab.eidentity.jp/2012/05/fim2010.html
管理エージェント
[FIM2010]Google Apps MA 1.1.0 をリリースしました
http://idmlab.eidentity.jp/2012/10/fim2010google-apps-ma-110.html
1のカスタムクライアントはWindows PhoneやiOSなどで承認フローを回すような製品などが世の中にはリリースされていたりしますし、カスタムワークフローについても実際の導入を行う際は確実に実装をする対象になってくると思います。
と、いうことで今後カスタムワークフローの紹介も本ブログでしていこうと思っています。今回はその中で環境面の話なので順番的には微妙なのですが、ちょうどFIM MVPのCraigさんとSorenさんが作成したカスタムワークフロー（dll）をグローバルアセンブリキャッシュ（GAC）へ取り込む方法について紹介していたので、その方法を紹介します。
通常、作成したdllをGACに取り込むには.NET Framework SDKをインストールして、その中に含まれているgacutil.exeを使うことになるのですが、あんまり環境を汚したくない人向けにgacutilを使わなくても取り込むためのスクリプト（PowerShell）を先の二人が公開してくれています。
Craig Martin氏のブログ - Identity Trench
Use PowerShell to GAC a FIM Workflow DLL without gacutil.exe
http://www.identitytrench.com/2013/09/use-powershell-to-gac-fim-workflow-dll.html?utm_source=dlvr.it&utm_medium=facebook
Soren Granfeldt氏のブログ - The Identity Management Explorer
Use Powershell to put your assemblies in the GAC
http://blog.goverco.com/2012/04/use-powershell-to-put-your-assemblies.html?m=1
参考にしてみてください。
- カスタムクライアント
- カスタムワークフロー
- ユーザインターフェイス（UI）
- 管理エージェント
これまでこのブログで紹介したことがあるのは3番目のUIのカスタマイズと、4番目の管理エージェントの作成方法でした。
ユーザインターフェイス（UI)
[FIM2010] ポータルのナビゲーションバーをカスタマイズする
http://idmlab.eidentity.jp/2012/05/fim2010.html
管理エージェント
[FIM2010]Google Apps MA 1.1.0 をリリースしました
http://idmlab.eidentity.jp/2012/10/fim2010google-apps-ma-110.html
1のカスタムクライアントはWindows PhoneやiOSなどで承認フローを回すような製品などが世の中にはリリースされていたりしますし、カスタムワークフローについても実際の導入を行う際は確実に実装をする対象になってくると思います。
と、いうことで今後カスタムワークフローの紹介も本ブログでしていこうと思っています。今回はその中で環境面の話なので順番的には微妙なのですが、ちょうどFIM MVPのCraigさんとSorenさんが作成したカスタムワークフロー（dll）をグローバルアセンブリキャッシュ（GAC）へ取り込む方法について紹介していたので、その方法を紹介します。
通常、作成したdllをGACに取り込むには.NET Framework SDKをインストールして、その中に含まれているgacutil.exeを使うことになるのですが、あんまり環境を汚したくない人向けにgacutilを使わなくても取り込むためのスクリプト（PowerShell）を先の二人が公開してくれています。
Craig Martin氏のブログ - Identity Trench
Use PowerShell to GAC a FIM Workflow DLL without gacutil.exe
http://www.identitytrench.com/2013/09/use-powershell-to-gac-fim-workflow-dll.html?utm_source=dlvr.it&utm_medium=facebook
Soren Granfeldt氏のブログ - The Identity Management Explorer
Use Powershell to put your assemblies in the GAC
http://blog.goverco.com/2012/04/use-powershell-to-put-your-assemblies.html?m=1
参考にしてみてください。
2013年9月7日土曜日
Bearer Token とは？
先日の OpenID Technight の後の懇親会で OpenID Foundation 理事長の崎村さんと飲みながら話をしていて、「言われてみれば・・・」と思ったのが、「OAuth などの Bearer Token の Bearer ってなんのことだと思う？」という話題でした。
OAuth 2.0 では通常 Bearer もしくは MAC というタイプのトークンが使われ、単純に違いは Secret や署名の要否という理解だったので、Bearer が何を意味するのか？を考えたことはなかったんですが、言われてみると気になります。
辞書を引くと
・運ぶ人[もの],運搬人
・持参人
などという意味があるようです。
※weblio より
相変わらずこの手の用語は直訳しても良くわからないです。。。
ということで、崎村さんによる解説です。
・Bearer は「持参人払い」から来ている
※大辞林によると「持参人払い＝小切手などの証書で，特定の者を権利者として指定せず，それを持参した人に支払うこと」
・つまり、トークンを持ってきた人に対して支払う（API 利用を許可する）、という意味である
・例えば、飛行機のチケットは持ってきた人が権利者かどうかの確認を行うが、演劇のチケットは持ってきた人が観劇できる。この演劇のチケットが Bearer である
なるほど。わかりやすい。
OAuth などのトークンに置き換えると、Bearer トークンを使う場合、使用されるトークンが誰に対して発行されたのかを確認せずに、「トークンを持っていること」をベースに API 利用を許可する、ということですね。
RFC などの仕様や実装における用法を勉強するのはもちろん大事ですが、使われる用語の意味にはちゃんと設計思想が反映されているので、ちゃんと理解しておきたいところです。
OAuth 2.0 では通常 Bearer もしくは MAC というタイプのトークンが使われ、単純に違いは Secret や署名の要否という理解だったので、Bearer が何を意味するのか？を考えたことはなかったんですが、言われてみると気になります。
辞書を引くと
・運ぶ人[もの],運搬人
・持参人
などという意味があるようです。
※weblio より
相変わらずこの手の用語は直訳しても良くわからないです。。。
ということで、崎村さんによる解説です。
・Bearer は「持参人払い」から来ている
※大辞林によると「持参人払い＝小切手などの証書で，特定の者を権利者として指定せず，それを持参した人に支払うこと」
・つまり、トークンを持ってきた人に対して支払う（API 利用を許可する）、という意味である
・例えば、飛行機のチケットは持ってきた人が権利者かどうかの確認を行うが、演劇のチケットは持ってきた人が観劇できる。この演劇のチケットが Bearer である
なるほど。わかりやすい。
OAuth などのトークンに置き換えると、Bearer トークンを使う場合、使用されるトークンが誰に対して発行されたのかを確認せずに、「トークンを持っていること」をベースに API 利用を許可する、ということですね。
RFC などの仕様や実装における用法を勉強するのはもちろん大事ですが、使われる用語の意味にはちゃんと設計思想が反映されているので、ちゃんと理解しておきたいところです。
2013年9月5日木曜日
JWx 仕様の日本語翻訳版が公開されました
以前より OpenID Authentication や OAuth 2.0 などの仕様の日本語化を行ってきた OpenID Foundation Japan の翻訳・教育ワーキング・グループにより JWx の翻訳版が公開されました。
本当は昨日（9/4）の OpenID Technight での発表の現場へ駆けつけたかったんですが、残念ながら大雨で足止めをされてしまい、間に合わず。。。
今回公開されたのは、以下の3点です。
Windows Azure Active Directory の API や Google Apps の API、Salesforce.com の API を Forefront Identity Manager（FIM）をはじめとする IdM 製品から実行するようなケースではこれまで各接続先に対する設定に管理者の ID とパスワードを埋め込んだりする必要がありましたが、JWT を使った OAuth 2.0 の認可を行う形へ各社の API が対応してきているので、今後はそのようなリスクのある運用はしなくても良くなると思われます。今のうちに JWx に慣れ親しんでおく良い機会になると思いますので、ぜひ参考にしてください。
（私は JWT の部分で協力させていただいています）
参考）これまでに翻訳された仕様一覧はこちらから。
http://openid-foundation-japan.github.io/
本当は昨日（9/4）の OpenID Technight での発表の現場へ駆けつけたかったんですが、残念ながら大雨で足止めをされてしまい、間に合わず。。。
今回公開されたのは、以下の3点です。
- JSON Web Token (JWT) draft-ietf-oauth-json-web-token-11
- JSON Web Signature (JWS) draft-ietf-jose-json-web-signature-14
- Use Cases and Requirements for JSON Object Signing and Encryption (JOSE) draft-ietf-jose-use-cases-03
Windows Azure Active Directory の API や Google Apps の API、Salesforce.com の API を Forefront Identity Manager（FIM）をはじめとする IdM 製品から実行するようなケースではこれまで各接続先に対する設定に管理者の ID とパスワードを埋め込んだりする必要がありましたが、JWT を使った OAuth 2.0 の認可を行う形へ各社の API が対応してきているので、今後はそのようなリスクのある運用はしなくても良くなると思われます。今のうちに JWx に慣れ親しんでおく良い機会になると思いますので、ぜひ参考にしてください。
（私は JWT の部分で協力させていただいています）
参考）これまでに翻訳された仕様一覧はこちらから。
http://openid-foundation-japan.github.io/
2013年8月15日木曜日
ID&IT Management Conference 2013に参加します
現在国内で開催されるエンタープライズ向けのアイデンティティ管理関連のイベントといえば、
・ID&IT Management Conference
・Japan Identity & Cloud Summit
の2つが主だと思います。
（コンシューマとか技術よりだと通称 idcon の Identity Conference とか OpenID Technight などもあります）
そのうち、ID&IT Management Conference 2013 が 9/18@大阪、9/20@東京で開催されます。
公式ページ
http://nosurrender.jp/idit2013/
昨年はカンターラ・イニシアティブの顔でシングルサインオンに関する技術動向についてのパネルディスカッションのモデレータをさせていただいたのですが、今年は日本ネットワークセキュリティ協会（JNSA）の顔で「THE 日本のID管理(SI編)～要求仕様策定のポイント～」と題してアイデンティティ管理システム／認証システムの導入に関する RFP をどうやって書くべきなのか？のポイントについてのパネルディスカッションのモデレータを担当することになりました。
公式サイトのプログラム紹介ページより
THE 日本のID管理(SI編)～要求仕様策定のポイント～日本のIAM分野のSIerが、認証基盤システム導入のための要求仕様(RFP)策定のポイントについてパネルディスカッションを行います。
内容についてはまだ考えている途中ですが、JNSAのアイデンティティ管理ワーキンググループで今年度のテーマの一つとして検討をしている、「アイデンティティ管理や認証システムの導入の目的と必要とする機能のマッピング」をベースに話をする予定です。
要するに、一言でアイデンティティ管理とか認証基盤と言っても何のためにシステム化をするのかによって必要となる機能は違うはずなので、単純に製品機能の有無（例えば対応する接続先アダプタの数など）で検討を進めてもあまり意味は無く、例えば運用コストを下げる目的ならばパスワードのセルフリセット機能などの自動化機能の重みが増しますよね、などといった話をしていこうと思います。
まだ、パネリストは未定ですが、導入経験の豊富な SIer のみなさんが登場してくれるはずなので、現場の生の声が聞けるチャンスだと思います。
平日の日中帯ですが、東阪の両方の会場でやりますので、都合がよろしければご来場ください。
2013年7月30日火曜日
[FIM2010/WAAD] Azure Active Directory コネクタ Pre-Release 版が Connect に登場
ようやく出てきました。
先日来、ちょこちょこアップデートについて投稿していた Office365 / Windows Azure Active Directory へ Forefront Identity Manager 2010（FIM）から直接接続するためのコネクタの Pre Release 版が Connect で公開されました。（ちなみに ECMA2.0 ベースのようです）
ダウンロードは以下 URL より（Connect への登録が必要です）
Windows Azure Active Directory Connector
https://connect.microsoft.com/site433/Downloads/DownloadDetails.aspx?DownloadID=50509
尚、今後も基本的にはディレクトリ同期ツールを使うことが推奨されるようですが、特殊なルールの適用をしたい場合や規模が大きい場合、フォレスト・ドメイン構成が複雑な場合などはこちらを使うことになりそうです。
関連ポスト
[Office365]新ディレクトリ同期ツールはFIM2010R2ベース
http://idmlab.eidentity.jp/2013/06/office365fim2010r2.html
[FIM2010]ついにディレクトリ同期ツールにビルド番号が追いつきました
http://idmlab.eidentity.jp/2013/06/fim2010.html
先日来、ちょこちょこアップデートについて投稿していた Office365 / Windows Azure Active Directory へ Forefront Identity Manager 2010（FIM）から直接接続するためのコネクタの Pre Release 版が Connect で公開されました。（ちなみに ECMA2.0 ベースのようです）
ダウンロードは以下 URL より（Connect への登録が必要です）
Windows Azure Active Directory Connector
https://connect.microsoft.com/site433/Downloads/DownloadDetails.aspx?DownloadID=50509
尚、今後も基本的にはディレクトリ同期ツールを使うことが推奨されるようですが、特殊なルールの適用をしたい場合や規模が大きい場合、フォレスト・ドメイン構成が複雑な場合などはこちらを使うことになりそうです。
関連ポスト
[Office365]新ディレクトリ同期ツールはFIM2010R2ベース
http://idmlab.eidentity.jp/2013/06/office365fim2010r2.html
[FIM2010]ついにディレクトリ同期ツールにビルド番号が追いつきました
http://idmlab.eidentity.jp/2013/06/fim2010.html
2013年7月20日土曜日
[WAAD] OAuth2.0 への対応状況まとめ＆ちょこっと OpenID Connect も
まず初めにお断りしておきますが、公式リソースでは Windows Azure Active Directory の OAuth2.0 への対応自体はアナウンスされていますが、内容について明確には言及がない状態なので、あくまで今日時点で色々と探索した結果を書いており、間違いや今後の変更などは高い確率で発生すると思われます。あくまで、エンドポイントを探して叩いてみたらこんな結果が返ってきた、という状態であるとご理解ください。
さて、始めます。
WAAD でアプリケーションを追加すると様々なエンドポイントが付与されます。
その中には OAuth2.0 のトークン・エンドポイントも含まれており、OAuth2.0 プロトコルで使う client_id や client_secret の取得、redirect_uri 等の設定もアプリケーションの構成の中で行うことが出来ます。
さらに、現状ではプレビュー提供ですが protected resource として同じく WAAD 上に構成したアプリケーションを登録することも可能であり、OAuth2.0 を使って WAAD 上のアプリケーション（API）をマッシュアップしていくことも可能になっています。
基本的には WAAD Authentication Library（AAL）を使ってアクセストークンなどを取得することが前提のようですが、折角そこに OAuth のエンドポイントがあるので叩いてみたいと思います。
まず、叩き方ですが、先日日本語訳がされた OAuth2.0 の仕様（RFC6749）に定義されている各種フローをそれぞれ試してみます。
The OAuth 2.0 Authorization Framework（OpenID Foundation Japan 翻訳 WG 訳）
- http://openid-foundation-japan.github.io/rfc6749.ja.html
試したのは、
・認可コードグラント
・インプリシットグラント
・リソースオーナーパスワードクレデンシャル
・クライアントクレデンシャル
です。
それぞれやってみます。
◆認可コードグラント
仕様上は、ざっくりいうと
１．クライアントが認可エンドポイントから認可コードを取得
２．トークンエンドポイントで認可コードとアクセストークンを交換
という流れになります。
ここで疑問。先ほど出てきた WAAD の OAuth2.0 エンドポイントにはトークンエンドポイントはありましたが、認可エンドポイントが出てきていませんでした。
トークンエンドポイントのアドレスが
https://login.windows.net/＜テナントID＞/oauth2/token?api-version=1.0
だったので、token ⇒ authorize に変えたら行けるかな？ということで
https://login.windows.net/＜テナントID＞/oauth2/authorize?api-version=1.0
を試してみます。意外と行けるもんです(笑)
ということで以下を試します。
１．認可コードの取得
エンドポイント：認可エンドポイント
メソッド：GET
パラメータ：
・response_type : code
・client_id : ＜WAADで取得した client_id＞
こんなクエリになります。
GET /＜テナントID＞/oauth2/authorize?api-version=1.0&response_type=code&client_id=＜client_id＞ HTTP/1.1
Host: login.windows.net
仕様上は HTTP 302 が返ってきて Location に redirect_uri?code=xxx という形で認可コードが返ってくるはずです。
結果、Microsoft Online アカウントでの認証が実行された後、ちゃんと認可コードが返ってきました。
２．認可コードとアクセストークンの交換
次は取得した認可コードをトークンエンドポイントへ投げてアクセストークンを取得します。
エンドポイント：トークンエンドポイント
メソッド：POST
パラメータ：
・grant_type : authorization_code
・code : ＜取得した認可コード＞
・resource : アクセス対象の保護リソースの URI（WAAD 上で指定した WebAPI のURI）。今回は Graph API の URI（https://graph.windows.net）を指定します。
※OAuth2.0 の仕様上は resource パラメータは存在しませんが、WAAD の OAuth2.0 エンドポイントへアクセスする場合は必ず resource パラメータを要求されます。
POST /＜テナントID＞/oauth2/token HTTP/1.1 Host: login.windows.net
Content-Type: application/x-www-form-urlencoded grant_type=authorization_code&code=＜取得した認可コード＞&resource=https%3A%2F%2Fgraph.windows.net
結果、残念ながら、「unsupported_grant_type」が返ってきてしまいました。
エラーの説明として「ACS70003: The access grant 'authorization_code' is not supported」とあるので、現状は認可コードグラントは使えない、ということです。
◆インプリシットグラント
次はインプリシットグラントです。こちらは非常に単純なフローで、認可エンドポイントに対してアクセストークンを直接要求します。
エンドポイント：認可エンドポイント
メソッド：GET
パラメータ：
・response_type : token
・client_id : ＜WAADで取得した client_id＞
こんなクエリになります。
GET /＜テナントID＞/oauth2/authorize?api-version=1.0&response_type=token&client_id=＜client_id＞ HTTP/1.1
Host: login.windows.net
仕様上は HTTP 302 が返ってきて Location に redirect_uri#access_token=xxx&token_type=xxx という形でフラグメントにアクセストークンが返ってくるはずです。
しかし、これも残念。「unsupported_response_type」といわれてしまいます。こちらも使えない、といことです。
◆リソースオーナーパスワードクレデンシャル
続いてリソースオーナーパスワードクレデンシャルです。こちらも単純でリソースオーナーのユーザ名とパスワードをクエリに埋め込んでアクセストークンを要求します。
エンドポイント：トークンエンドポイント
メソッド：POST
パラメータ：
・grant_type : password
・username : ＜WAADのユーザ名＞
・password : ＜WAADのパスワード＞
・resource : https://graph.windows.net
こんなクエリになります。
POST /＜テナントID＞/oauth2/token HTTP/1.1 Host: login.windows.net
Content-Type: application/x-www-form-urlencoded grant_type=password&username=＜WAADのユーザ名＞&password=＜WAADのパスワード＞&resource=https%3A%2F%2Fgraph.windows.net
こちらもうまくいけば HTTP 200 でアクセストークンが返ってくるはずです。
しかし、同じくこちらも残念ながら「unsupported_grant_type」です。なかなかうまく行かないもんです。
◆クライアントクレデンシャルグラント
最後はクライアントクレデンシャルグラントです。こちらはトークンエンドポイントへ直接トークンを要求します。
エンドポイント：トークンエンドポイント
メソッド：POST
パラメータ：
・grant_type : client_credentials
・client_id : ＜取得した client_id＞
・client_secret : ＜取得した client_secret＞
・resource : https://graph.windows.net
※こちらも仕様上は grant_type 以外のパラメータは必須ではありませんが、認証を行うことが必要なフローなので、WAAD では client_id と client_secret を投げてクライアント認証を行っているようです。
こんなクエリになります。
POST /＜テナントID＞/oauth2/token HTTP/1.1 Host: login.windows.net
Content-Type: application/x-www-form-urlencoded grant_type=client_credentials&client_id=＜取得した client_id＞&client_secret=＜取得した client_secret＞&resource=https%3A%2F%2Fgraph.windows.net
うまくいけば HTTP 200 でアクセストークンが返ってくるはずです。
こちらは、、、、、うまく行きました。
{
"token_type":"Bearer",
"access_token":"eyJ0eX........（略）",
"expires_in":"43199",
"not_before":"1374294762",
"expires_on":"1374337962",
"resource":"https://graph.windows.net"
}
と、いうことで結果をまとめると下記の通りとなります。
まぁ、まだまだですねぇ。
◆おまけ（OpenID Connect）
ここからはおまけですが、WAAD も OpenID Connect に対応するという話があります。OpenID Connect は OAuth2.0 ベースなので少し試してみました。
試したのはインプリシットのみで、結果的に言うと id_token の取得が出来てしまいました。が、仕様への対応状況はまだかなり怪しい感じです。
エンドポイント：認可エンドポイント
メソッド：GET
パラメータ：
・response_type : id_token token
・client_id : ＜WAADで取得した client_id＞
・scope : openid profile
・nonce : ＜任意の文字列＞
こんなクエリになります。
GET /＜テナントID＞/oauth2/authorize?api-version=1.0&response_type=id_token%20token&client_id=＜client_id＞&scope=openid%20profile&nonce=＜任意の文字列＞ HTTP/1.1
Host: login.windows.net
仕様上は HTTP 302 が返ってきて Location に redirect_uri#id_token=xxx&access_token=xxx&token_type=xxx という形でフラグメントに ID トークンとアクセストークンが返ってくるはずです。
しかし、先に述べたように response_type に token を指定するとエラーになるので、今回は response_type = id_token のみを指定してみました。
すると、フラグメントではなく、パラメータで id_token が返ってきました。
返ってきた id_token を BASE64 URL デコードしてみると、
{
"typ":"JWT",
"alg":"RS256",
"x5t":"NGTFvdK-fythEuLwjpwAJOM9n-A"
}
{
"aud":"＜取得した client_id＞",
"iss":"https://sts.windows.net/＜テナント ID＞/",
"nbf":1374284435,
"exp":1374313235,
"ver":"1.0",
"tid":"＜テナントID＞",
"oid":"＜WAAD 上のユーザのオブジェクトID＞",
"upn":"xxx@＜テナントドメイン＞.onmicrosoft.com",
"sub":"vqrPXdoNdGPRd5DBnH...（略）",
"family_name":"富士榮",
"given_name":"尚寛",
"nonce":"hoge"
}
という形になりました。
sub に入っている値が何なのか、Graph API 等で探ってみたのですが、利用者に見えるところには出てこない識別子のようです。
まだ、これで何か出来るわけではありませんが、Office Web App の開発リファレンスを見ているとトークンのデコードや検証のためのサンプルコードが出ていたりするので、同じ仕組みを使うことが出来るようです。
今回、色々と課題はあるものの WAAD が着々と OAuth2.0 や OpenID Connect に対応してきていることが見えてきました。
今後は社内の Active Directory と AD FS ⇒ WAAD を経由して OpenID Connect RP への認証連携なども実現できるようになってきそうなので、ますますコンシューマ系のサービスとの接続が容易になってくるのかも知れません。
引き続き目が離せないところです。
さて、始めます。
WAAD でアプリケーションを追加すると様々なエンドポイントが付与されます。
その中には OAuth2.0 のトークン・エンドポイントも含まれており、OAuth2.0 プロトコルで使う client_id や client_secret の取得、redirect_uri 等の設定もアプリケーションの構成の中で行うことが出来ます。
さらに、現状ではプレビュー提供ですが protected resource として同じく WAAD 上に構成したアプリケーションを登録することも可能であり、OAuth2.0 を使って WAAD 上のアプリケーション（API）をマッシュアップしていくことも可能になっています。
基本的には WAAD Authentication Library（AAL）を使ってアクセストークンなどを取得することが前提のようですが、折角そこに OAuth のエンドポイントがあるので叩いてみたいと思います。
まず、叩き方ですが、先日日本語訳がされた OAuth2.0 の仕様（RFC6749）に定義されている各種フローをそれぞれ試してみます。
The OAuth 2.0 Authorization Framework（OpenID Foundation Japan 翻訳 WG 訳）
- http://openid-foundation-japan.github.io/rfc6749.ja.html
試したのは、
・認可コードグラント
・インプリシットグラント
・リソースオーナーパスワードクレデンシャル
・クライアントクレデンシャル
です。
それぞれやってみます。
◆認可コードグラント
仕様上は、ざっくりいうと
１．クライアントが認可エンドポイントから認可コードを取得
２．トークンエンドポイントで認可コードとアクセストークンを交換
という流れになります。
ここで疑問。先ほど出てきた WAAD の OAuth2.0 エンドポイントにはトークンエンドポイントはありましたが、認可エンドポイントが出てきていませんでした。
トークンエンドポイントのアドレスが
https://login.windows.net/＜テナントID＞/oauth2/token?api-version=1.0
だったので、token ⇒ authorize に変えたら行けるかな？ということで
https://login.windows.net/＜テナントID＞/oauth2/authorize?api-version=1.0
を試してみます。意外と行けるもんです(笑)
ということで以下を試します。
１．認可コードの取得
エンドポイント：認可エンドポイント
メソッド：GET
パラメータ：
・response_type : code
・client_id : ＜WAADで取得した client_id＞
こんなクエリになります。
GET /＜テナントID＞/oauth2/authorize?api-version=1.0&response_type=code&client_id=＜client_id＞ HTTP/1.1
Host: login.windows.net
仕様上は HTTP 302 が返ってきて Location に redirect_uri?code=xxx という形で認可コードが返ってくるはずです。
結果、Microsoft Online アカウントでの認証が実行された後、ちゃんと認可コードが返ってきました。
２．認可コードとアクセストークンの交換
次は取得した認可コードをトークンエンドポイントへ投げてアクセストークンを取得します。
エンドポイント：トークンエンドポイント
メソッド：POST
パラメータ：
・grant_type : authorization_code
・code : ＜取得した認可コード＞
・resource : アクセス対象の保護リソースの URI（WAAD 上で指定した WebAPI のURI）。今回は Graph API の URI（https://graph.windows.net）を指定します。
※OAuth2.0 の仕様上は resource パラメータは存在しませんが、WAAD の OAuth2.0 エンドポイントへアクセスする場合は必ず resource パラメータを要求されます。
POST /＜テナントID＞/oauth2/token HTTP/1.1 Host: login.windows.net
Content-Type: application/x-www-form-urlencoded grant_type=authorization_code&code=＜取得した認可コード＞&resource=https%3A%2F%2Fgraph.windows.net
結果、残念ながら、「unsupported_grant_type」が返ってきてしまいました。
エラーの説明として「ACS70003: The access grant 'authorization_code' is not supported」とあるので、現状は認可コードグラントは使えない、ということです。
◆インプリシットグラント
次はインプリシットグラントです。こちらは非常に単純なフローで、認可エンドポイントに対してアクセストークンを直接要求します。
エンドポイント：認可エンドポイント
メソッド：GET
パラメータ：
・response_type : token
・client_id : ＜WAADで取得した client_id＞
こんなクエリになります。
GET /＜テナントID＞/oauth2/authorize?api-version=1.0&response_type=token&client_id=＜client_id＞ HTTP/1.1
Host: login.windows.net
仕様上は HTTP 302 が返ってきて Location に redirect_uri#access_token=xxx&token_type=xxx という形でフラグメントにアクセストークンが返ってくるはずです。
しかし、これも残念。「unsupported_response_type」といわれてしまいます。こちらも使えない、といことです。
◆リソースオーナーパスワードクレデンシャル
続いてリソースオーナーパスワードクレデンシャルです。こちらも単純でリソースオーナーのユーザ名とパスワードをクエリに埋め込んでアクセストークンを要求します。
エンドポイント：トークンエンドポイント
メソッド：POST
パラメータ：
・grant_type : password
・username : ＜WAADのユーザ名＞
・password : ＜WAADのパスワード＞
・resource : https://graph.windows.net
こんなクエリになります。
POST /＜テナントID＞/oauth2/token HTTP/1.1 Host: login.windows.net
Content-Type: application/x-www-form-urlencoded grant_type=password&username=＜WAADのユーザ名＞&password=＜WAADのパスワード＞&resource=https%3A%2F%2Fgraph.windows.net
こちらもうまくいけば HTTP 200 でアクセストークンが返ってくるはずです。
しかし、同じくこちらも残念ながら「unsupported_grant_type」です。なかなかうまく行かないもんです。
◆クライアントクレデンシャルグラント
最後はクライアントクレデンシャルグラントです。こちらはトークンエンドポイントへ直接トークンを要求します。
エンドポイント：トークンエンドポイント
メソッド：POST
パラメータ：
・grant_type : client_credentials
・client_id : ＜取得した client_id＞
・client_secret : ＜取得した client_secret＞
・resource : https://graph.windows.net
※こちらも仕様上は grant_type 以外のパラメータは必須ではありませんが、認証を行うことが必要なフローなので、WAAD では client_id と client_secret を投げてクライアント認証を行っているようです。
こんなクエリになります。
POST /＜テナントID＞/oauth2/token HTTP/1.1 Host: login.windows.net
Content-Type: application/x-www-form-urlencoded grant_type=client_credentials&client_id=＜取得した client_id＞&client_secret=＜取得した client_secret＞&resource=https%3A%2F%2Fgraph.windows.net
うまくいけば HTTP 200 でアクセストークンが返ってくるはずです。
こちらは、、、、、うまく行きました。
{
"token_type":"Bearer",
"access_token":"eyJ0eX........（略）",
"expires_in":"43199",
"not_before":"1374294762",
"expires_on":"1374337962",
"resource":"https://graph.windows.net"
}
と、いうことで結果をまとめると下記の通りとなります。
まぁ、まだまだですねぇ。
| フロー | 結果 | 備考 |
|---|---|---|
| 認可コードグラント | × | Code requetは成功 Token requestでunsupported_grant_type |
| インプリシットグラント | × | unsupported_response_type |
| リソースオーナーパスワードクレデンシャル | × | unsupported_grant_type |
| クライアントクレデンシャルグラント | ○ | 以下のパラメータが要求される Resource Client_id Client_secret |
◆おまけ（OpenID Connect）
ここからはおまけですが、WAAD も OpenID Connect に対応するという話があります。OpenID Connect は OAuth2.0 ベースなので少し試してみました。
試したのはインプリシットのみで、結果的に言うと id_token の取得が出来てしまいました。が、仕様への対応状況はまだかなり怪しい感じです。
エンドポイント：認可エンドポイント
メソッド：GET
パラメータ：
・response_type : id_token token
・client_id : ＜WAADで取得した client_id＞
・scope : openid profile
・nonce : ＜任意の文字列＞
こんなクエリになります。
GET /＜テナントID＞/oauth2/authorize?api-version=1.0&response_type=id_token%20token&client_id=＜client_id＞&scope=openid%20profile&nonce=＜任意の文字列＞ HTTP/1.1
Host: login.windows.net
仕様上は HTTP 302 が返ってきて Location に redirect_uri#id_token=xxx&access_token=xxx&token_type=xxx という形でフラグメントに ID トークンとアクセストークンが返ってくるはずです。
しかし、先に述べたように response_type に token を指定するとエラーになるので、今回は response_type = id_token のみを指定してみました。
すると、フラグメントではなく、パラメータで id_token が返ってきました。
返ってきた id_token を BASE64 URL デコードしてみると、
{
"typ":"JWT",
"alg":"RS256",
"x5t":"NGTFvdK-fythEuLwjpwAJOM9n-A"
}
{
"aud":"＜取得した client_id＞",
"iss":"https://sts.windows.net/＜テナント ID＞/",
"nbf":1374284435,
"exp":1374313235,
"ver":"1.0",
"tid":"＜テナントID＞",
"oid":"＜WAAD 上のユーザのオブジェクトID＞",
"upn":"xxx@＜テナントドメイン＞.onmicrosoft.com",
"sub":"vqrPXdoNdGPRd5DBnH...（略）",
"family_name":"富士榮",
"given_name":"尚寛",
"nonce":"hoge"
}
という形になりました。
sub に入っている値が何なのか、Graph API 等で探ってみたのですが、利用者に見えるところには出てこない識別子のようです。
まだ、これで何か出来るわけではありませんが、Office Web App の開発リファレンスを見ているとトークンのデコードや検証のためのサンプルコードが出ていたりするので、同じ仕組みを使うことが出来るようです。
今回、色々と課題はあるものの WAAD が着々と OAuth2.0 や OpenID Connect に対応してきていることが見えてきました。
今後は社内の Active Directory と AD FS ⇒ WAAD を経由して OpenID Connect RP への認証連携なども実現できるようになってきそうなので、ますますコンシューマ系のサービスとの接続が容易になってくるのかも知れません。
引き続き目が離せないところです。
登録:
投稿 (Atom)
投稿
