どうも、事務局長の Nov です。
どうも、ジムキョクチョのノブです。
どうも、ノブキョクチョです。
どうも、のぶチョです。
そう、のぶ千代です。
最近歳のせいか、Rails で SAML IdP とか作ってます。
今日は自作 SAML IdP を Office 365 と連携させてみたので、その格闘の記録を残しておきます。
Office 365 の制約とか Azure AD の制約とか全く前提知識なしに格闘した記録なんで、そういうのいいから手っ取り早くやり方教えろやって人は我らがふぁらおぅ兄さんのこちらの連載をご覧ください。
あとはこの本もおすすめ。
どうも、この度 OpenID Foundation Japan の事務局長になった Nov です。
事務局長就任のご挨拶的なポエムを書けというオーラをふつふつと感じながら、ガン無視してこの記事を書いております。
さて、みなさん覚えておられるでしょうか？
OpenID Foundation Japan 翻訳 Working Group のことを。
僕が OpenID のエバンジェリストになる前からリーダーをしており、古くは 2010 年に今は亡き OpenID 2.0 の仕様を翻訳していた、あの伝説の WG を。
その伝説の WG が、2年超の休眠期間を終えて、ついに復活します！
復活第一弾は、OAuth Revocation と JWK！
え、この2つにどういう関連性があるのかって？
特にないです！
JWK 翻訳しようとしたら、途中まで翻訳されて休眠してた OAuth Revocation の存在を思い出しただけです！
Read on →先日 Office 365 のこんな記事見つけたので、一応まとめておきますかね。
The road to hell is paved with SAML Assertions
タイトルだけ見るとまた SAML is DEAD 案件かと思いきや、Office 365 の脆弱性の話です。
SAML 悪く無いです。
SAML isn’t vulnerable, just DEAD.
Office 365 は SAML Service Provider (SP) として動作するので、みなさんがお持ちの Identity Provider (IdP) を SAML IdP として動作することができれば、みなさんの IdP に登録されてるアカウントを使って Office 365 にログインすることができます。
みなさんの社内の ADFS とか、Ping Federate / Okta / OneLogin … みたいな IDaaS とか、そういうのは大抵 SAML IdP として動作するので、そういう製品を使ってるなら、みなさんの会社のアカウントでそのまま Office 365 にログインできます。
通常 SAML SP は、IdP から返ってくる SAML Response に含まれる IdP 側のユーザー識別子 (Subject Identifier) と IdP 自身の識別子 (Issuer Identifier) のペアを元に、SP 側のアカウントにログインさせます。
がしかし、Office 365 の場合は、IdP が渡してくる Email アドレスと Office 365 がローカルで持ってる Email アドレスの一致だけを見て Office 365 ローカルのユーザーを認証していたようです。Subject Identifier も Issuer Identifier も無視していた、と。
(実際には、SAML IdP と Office 365 の間に Azure AD が介在しており、SAML Assertion の検証は Azure ADがやるようなアーキテクチャになっていて、Azure AD では Subject Identifier & Issuer Identifier をちゃんと見ているようですが、全体として見ると Office 365 が SAML IdP の Issuer と Subject をガン無視した形になってます。この辺の話しだすとややこしい割に MS 以外の人にはあまり関係無い話になっちゃうので、今回はスルー)
これで何が起こっていたかというと、nov@victim.example.com という Email アドレスを持つ Office 365 ユーザーのアカウントにログインする際に、attacker.example.com という IdP が nov@victim.example.com という Email アドレスを含んだ SAML Assertion を発行すると、Office 365 がその Assertion を受け入れて nov@victim.example.com の Office 365 アカウントへのログインを許可してしまっていました。
よって、以下の2つのパターンが、どちらも同じ Office 365 アカウントにログイン可能になっていました。
| Issuer Identifier | Subject Identifier | Email Address | |
|---|---|---|---|
| attacker.example.com | 58df3c9b2c32ca86f.. | nov@victim.example.com |
|
| victim.example.com | 20166f0c077c1f6c1.. | nov@victim.example.com |
うん、これは最悪ですね。
Read on →昨日こんなのが OAuth ML に流れてました。
[OAUTH-WG] Another CSRF attack
RP (Relying Party a.k.a. OAuth Client) が2つ以上の IdP (Identity Provider a.k.a. OAuth Server) と連携している状況で、片方の IdP に悪意がある。
state パラメータをつけている。code を取得する。code を、RP の HIdP 用 redirect_uri に返す。
state を付与する。state を検証した上で code を HIdP の Token Endpoint に送る。access_token を返す。そして、Attacker は任意のタイミングで自身の HIdP 上のアカウントを使って、RP 上の Victim のアカウントにログインできる。
state をリクエスト先の IdP とも紐づけましょう。
今日は Azure Function で FB Message API Callback を作ってみます。
Azure Function は、Azure Portal の Marketplace で “Function App” って検索すると出てきますね。
Function App の Deploy がおわったら、QuickStart から “Webhook + API” を選びましょう。
以下の様な Node.js のテンプレートアプリが出来上がります。
まずは FB Message の WebHook としてこの Function を登録します。
Read on →