20090410 idcon stomita
DESCRIPTION
idcon#5 @ NTT musashino labTRANSCRIPT
idcon#5WebブラウザハックとアイデンティティWebサービスについて
Apr 10, 2009
株式会社マッシュマトリックス冨田 慎一
はじめに• idconでのプレゼン自体は初めてなので、自己
紹介
• id:shinichitomita
• twitter.com/stomita
• 会社やってます(株式会社マッシュマトリックス)
• 企業向けマッシュアップのミドルウェア提供/コンサルティングとか
位置づけ• アイデンティティ愛好家(自称)
『手に何も持たぬから̶̶̶̶空手』『そう教えられてきたハズの両雄だった…』『しかし̶̶̶』『歩んだ日常があまりにも違っていた』『その違いが̶̶̶』『一方を空手家へ』『もう一方を空手愛好家へと道を分けた』
餓狼伝 Vol.216 より
• 愛好家とプロフェッショナルの違い
• 背負ってたつものがないので、気楽にできる(重要)
• 裏を取る作業を怠るので、穴が多い(=信頼感にかける)
切り口• テーマ:
• 軽量Webサービスとアイデンティティの融合
• アイデンティティWebサービスの企業内情報統合への利用(本業に近い)
• ポリシー:
• できるだけ専門用語を使わない
• 仕様は必要なときしか見ない。そこはプロに任せる
• ブログ書くときはさすがにちょっと調べるが、付け焼き刃。きっと間違ってたらだれか教えてくれるはず、という甘い期待
重要なこと• アイデンティティWebサービスが市民権を得
た
• 少なくとも、デベロッパーには解放された
• プロトコルはどうあれ、Libertyがやりたかった世界に近づいてきた
• 今新卒エンジニアだったら、絶対あそんでる
近代• その昔、Liberty Allianceがあった
(もちろん今もある)
• 2000年新卒当時、Sunの下道さんとか
• 有名な航空券予約デモ
• これがほんとのWebサービスですか!(単純な新卒脳を洗脳)
現代• Liberty => SAML は、当初の「インターネッ
トにおけるアイデンティティ連携」の主流からは外れてきたように思える
• しかしB2B、SaaS連携では着実に実績がある
• プライバシーなど仕様にもりこまれてるため、安心
• ファイアウォールをまたいだ連携
• Google Apps, Salesforce の2大SaaSがともに採用
• あまり人目に触れにくいのが残念なところ
Open Stack の勝因?• サービス側主導で採用
• 今すぐに見えるものがある、というのは重要
• オープンソースコミュニティ
• 軽さ、とっつきやすさ、自由度
• たとえ無償で出しても、インストール&セットアップに1日かかるなら、コミュニティはスケールしない
OpenID の悩み• ユーザビリティ低くね?
• 選択の自由なんかいらない、って人が多数じゃない?
• 仕様は自由だが、運用は固定でもOK
• ホワイトリスト、「Yahooでログイン」ボタン
• ユーザはあまり標準仕様とかどうかとか気にしない
プロプラへの回帰• どうせ大人の事情で「ユーザが完全自由に選
択」なんてできないし、そもそもユーザがそれを望んでるかどうかが怪しい
• じゃあ今のところ独自の仕様でも別にいいよね?(常人には危険な発想)
• そのかわり、もっと普及を促進するようなアイディアを盛り込めないか(?)
Facebook Connect• ポルシェ乗り回してVCから総スカン食らった
現マイクロソフト Dick Hardt、絶賛• Facebook Connect - fatal blow for OpenID?
http://identity20.com/?p=151
• アイデンティティ・サイロを批判してたはずなのに?(どうしたの?)
FBCのいいところ• ログインが直感的
• 「Connect with Facebook」ボタン
• ポップアップで連携をユーザに確認
• “I want sign in to Yelp, so keep me on the Yelp site”
• OP側が小さい画面に最適化したプロンプト画面を提供
• inline frame での表示はユーザの邪魔をしないが、もしかしたら昨今問題(クリックジャックとか)?全部ウインドウポップアップになる?
• OpenID UXにノウハウ吸収される
• MySpace 等、既に Popup Experienceを実装
• OpenID UEX Summit (2009/02/10) @ facebook
• http://therealmccrea.com/2009/02/10/live-blogging-the-openid-design-summit/
Google Friend Connect• 「Facebook Connectの対抗馬」と喧伝され
る
• ソーシャルグラフの解放、流通を目指す
• 最初はウィジット型での提供だったのでFBCとの差異は多かった
• 今はAPIとして提供され、Facebook Connect に近づいた
FBC、GFCの共通点• Consumer側にサーバ実装が要らない!
• HTML+JavaScriptで完結• Google Maps API• ブログにスクリプトを貼付けるだけでFacebook/GFCの
サービスを利用できる• ブラウザ拡張とはちがう、事前のインストール必要なし• コピペでばらまき可能であることのスケーラビリティ、
ウィジット化
• 同様の試み(ブラウザのみでWebサービス接続)
• Google GData JS API (Google Account Auth AuthSub JS)• GoogleカレンダーのプライベートカレンダーにJSのみでアクセス
できる
技術(ハック)による克服点• ブラウザ上でのクロスドメインコミュニケーショ
ンをどう実現するか
• 通常セキュリティ制約により通信できない => Hack
• IFRAME越しのフラグメント識別子通信
• window.postMessage (only for relatively modern browsers)
• ユーザに同意させる仕組みはどうするか
• 認証トークンのやり取りはどうするか
• フラグメント識別子 => Cookie保存
• 署名は省く
個人的見解• 「HTML+JavaScriptのみ」で、参入敷居が下がるなら歓
迎。”開発者 = Code書き” の式はどこまで壊せるか?
• 独自仕様は。。。
• でも実装にハックが多いので、標準仕様にするのは難しくないか?
• まずはプロプラ実装が可能性を示すのは、正常な進化である気がする
• アクティビティストリームへの吸い上げに有効
• FBやGoogleがFBC/GFCを出してる主な理由
• 情報アグリゲーション型の軽量マッシュアップにも有効
• 複雑なことをやろうとすると、サーバが絡むだろうから、そうなるとあまりかわらないかも
• 日本は携帯対応でないと、という冷ややかな反応
OAuth XD JS Proxy• OAuthプロテクトされたリソースを
HTML+JavaScriptから直接呼び出せるように変換するプロキシサービス
• プロキシサービスは Google App Engine 上で稼働
• 同意や署名等はプロキシ側で実装ずみ
• クロスドメイン通信=window.name + iframe fragment identifier
• http://d.hatena.ne.jp/shinichitomita/20090401/1238581497
• http://xdoauthproxy.appspot.com/