iOSのTwitter統合とAndroidのAccountManager、そしてBrowserIDに見るUser-Centric Identityの再来？について - snippets from shinichitomita’s journal
最近、自分自身のテクノロジー的な世界観に対して影響を与える刺激がいろいろとあったわけだけど、その中におぼろげながら共通点が感じられたので、最初はGoogle+にLimitedなメモとして書いたのだが、ブログの方に清書する。 - 最初のきっかけは、AppleのiOS5へTwitter APIが組み込まれる、というニュースだった。それはTwitterサービスにiOSの提供するAPIを通してアクセスでき、その際の認証はOSが代行してくれる、というものだ。それが基調講演で発表された時には「なんでそこにOSが絡まなきゃいけないのか、オープンスタンダードなやり方があるのだからいいじゃないか」という理由で否定的に受け取ったわけだけども、よくよく考えてみれば位置情報でもストレージでも、リソースへのアクセス許可に対して承認許可ダイアログをOSが出しているわけだし、それがWebサービスでもまあありかもな、と考
Google FriendConnect API公開の衝撃 | gihyo.jp
ついにGoogle FriendConnectのAPIドキュメントが公開されました。この衝撃が分かるでしょうか。2009年3月13日はインターネットが大きく変わった日として歴史に刻まれるかもしれません。 GFCがなぜそんなに大事件なのか、いくつかの例をもって順に説明していきます。 なお、本文中で使用する言葉をあらかじめ定義しておきます。 GFC：Google FriendConnect。 プロバイダ：GFCにソーシャルグラフを提供するGoogleやTwitterなどのサービス。 コンシューマ：GFCのAPIを使ってサービスを提供するソーシャルグラフを活用したウェブサービス。ブログ等も含む。 ユーザー：コンシューマまたはGFCを利用する人。 オープンソーシャルウェブがついに本格始動 Facebookはじめ様々なSNSがオープン化以降取り組んできたのが、あらゆる外部サイトにソーシャルグラフ（人
徳丸浩の日記 - 書籍「PHP×携帯サイト デベロッパーズバイブル」の脆弱性
_書籍「PHP×携帯サイト デベロッパーズバイブル」の脆弱性 「PHP×携帯サイト デベロッパーズバイブル」という携帯サイト開発のノウハウを解説した書籍が今月初頭に発売され、話題になっている。Amazonの「インターネット・Web開発」カテゴリで1位ということで、たいしたものだ。私も発売前から予約して購入した。 私がこの書籍を購入した動機は大きく二つある。一つは、携帯サイトの最新の開発ノウハウをまとめた書籍に対する期待をしていたということ。もう一つは、セキュリティに対する記述がどの程度あるのかを見てみたいというものだった。 このうち、前者については、期待は叶えられた。非常に盛りだくさんのテーマが手際よくまとめられていて、かつ読みやすい。あまり原理・理屈のことは書いていないが、開発現場では、コピペの情報源として重宝されることだろう。 しかし、問題はセキュリティについての記述である。 本社のサ
BASIC 認証でログアウトを可能にする方法 - kazuhoのメモ置き場
Cookie でログイン状態を管理すればいいんじゃいのかな。 まず、ログインボタンを押した時「だけ」is_logged_on を真にする。 HTTP/1.1 Authorization Required Set-Cookie: is_logged_on=1 WWW-Authenticate: Basic realm="Hoge123456" ...サーバ側では、Basic 認証のパスワードがあり、かつ、is_logged_on の値が真であることをチェックすればいい。 GET / HTTP/1.1 Cookie: is_logged_on=1 Authorization: Basic ... ... HTTP/1.1 200 OK ...で、ログアウトの際には、Cookie を消す。 HTTP/1.1 200 OK Set-Cookie: is_logged_on=0 ...そして、is_
「認証」に関するおさらいと taspo について — 旧メイン・ブログ | Baldanders.info
最近 OAuth だの OATH だの色々出てきているので， いわゆる「認証」について 『セキュリティはなぜやぶられたのか』（Beyond Fear） を教科書に少しおさらいしてみる。 いわゆる「認証」については， 前に読書禄でも紹介している。 いわゆる「認証」を考えるとき， 私たちは以下の3つの要素の組み合わせで考える。 識別（identification）： あなたは誰？ 認証（authentication）： 証明しろ 許可（authorization）： この範囲のことはしてもよい 例えば， 運転免許証番号は識別トークン， 運転免許証の顔写真は認証トークン， 運転免許証自体は許可トークン， といった具合である。 識別・認証・許可は必ずしもセットになっている必要はない。 『セキュリティはなぜやぶられたのか』 でも例示されているが， 乗り物の乗車券やコンサートのチケットは許可トークンだ
こめんと(2008-04-22) - MutualTestFox 公開
■ [Misc] 怒涛 うわー、なんか無茶苦茶忙しかった……。 とりあえず2件の発表を終えました。やること溜りまくりですねぇ。 ■ [Work] Fail-Safe C release 1 公開 というわけで、1つ目の発表は Fail-Safe C の正式版公開 です。 最初に函館で発表したのが2001年のJSSST大会*1 で、かれこれもう7年もかかってしまいましたので、プレスリリースは自分なりの1つの纏めとケジメのつもりです。 協力して頂いた皆様、本当にありがとうございました。 Slashdot をはじめいろいろ連絡とかバグレポとかフィードバックを頂いた皆様、対応が遅れていてすみません。 有難く早急に取り組ませて頂きたいと思います。 Fail-Safe C の研究を始めるに当たって「C言語を対象にする」と決めた時点で、 実用に供するというのは大前提の1つです。これからも Fail-Sa
産総研：パスワード相互認証プロトコルの技術評価用ソフトウェアを公開
発表・掲載日：2008/04/22 パスワード相互認証プロトコルの技術評価用ソフトウェアを公開 －抜本的なフィッシング詐欺防止技術の実用化に向けて－ ポイント インターネットにおけるフィッシング詐欺を防止できる新しい認証方式を開発。 技術評価用のウェブブラウザとサーバー用拡張モジュールをオープンソースで公開。 ウェブブラウザに標準搭載され、フィッシング被害が減少することに期待。 独立行政法人 産業技術総合研究所【理事長 吉川 弘之】（以下「産総研」という）情報セキュリティ研究センター【研究センター長 今井 秀樹】（以下「RCIS」という）とヤフー株式会社【代表取締役社長 井上 雅博】（以下「Yahoo! JAPAN」という）は、これまでインターネットにおけるフィッシング詐欺を防止する「ウェブでの利用に適したパスワード相互認証プロトコル」の研究開発を進めてきた。このたび、新しい認証プロトコル
AIST RCIS: Mutual Authentication Protocol for HTTP
Overview "HTTP Mutual Access Authentication Protocol" is a proposed new protocol for preventing Phishing attacks against Web systems. This protocol provides true mutual authentication between HTTP clients and servers using simple password-based authentication. Unlike Basic and Digest HTTP access authentication protocol, the protocol ensures that the server knows the user's entity (encrypted passwo
Webブラウザにパスワード入力機能，産総研がFireｆoxとApacheモジュールを公開
産業技術総合研究所（産総研）とヤフーは2008年4月22日，パスワードを用いてWebブラウザ/サーバー間の相互認証を実現する認証プロトコル「HTTP Mutualアクセス認証」の実装をオープンソースとして公開した。同プロトコルを使うと，HTMLフォームではなくブラウザに設けた専用の入力域を用いてパスワードを暗号送信するため，フィッシング詐欺対策となる。サーバー側にはApacheのモジュール「mod_auth_mutual」として実装し，クライアント側としてFirefoxの機能を拡張したブラウザ「MutualTestFox」を開発した。 HTTP Mutualアクセス認証は，パスワードを用いてクライアントとサーバーが相互に相手を認証するプロトコルである。産総研とヤフーが2007年3月に発表した。同プロトコルの特徴は，ブラウザ上に設けた専用の入力域にパスワードを入力すると，暗号化処理を施した後
作者にはてなポイントを送るとページが閲覧できるようになる仕組み「Apach2::AuthzHatenaPoint」を作ってみたよ！ - id:lopnor
夜中に目が覚めたのでカッとなって作ってみた。けど中途半端だな。 ↓下のURLに行って、はてなのopenidでログインすると、次の画面で10ポイント支払いを求められます。払うと見えるようになります。なんもないけどね:P http://lopnor.homeip.net/~danjou/authenopenid/ この前のApache2::AuthenOpenIDと組み合わせて使います。例によってhttpd.confで LoadModule perl_module modules/mod_perl.so PerlLoadModule Apache2::AuthenOpenID PerlLoadModule Apache2::AuthzHatenaPoint のようにしてモジュールをロードし、↓こんな感じで.htaccessを書きます。.htsentuserdbというところに支払済みユーザーをた
SAMLについて自由勝手に紹介 - snippets from shinichitomita’s journal
宿題をid:ZIGOROuさんから課せられたので、早めにやっつけで片付けます。でも入門、というのとはちょっとちがうだろうな。今回は、SAMLを知っている人には当たり前の話でも、知らない人はきっとわからないだろうことを補足するだけです。しかもとみたの主観的におもしろいと思ってるところだけ。 そもそも僕自身の能力的な話で、Libertyの時代も仕様は気になったところしか読んでないので、網羅的に書くのは正直つらいし、割に合わないと感じてます。ただ、今回はきっとtkudoさんが添削してくれるはずなので、かなりのびのびと書いちゃいます。 歴史のおさらい まず間違え易い点として、SAML1.0とか1.1ってのは、SAMLが出たてのときの仕様なので、いまの話(v2.0)と結構違う。結構SAMLで検索するとこのころの話が引っかかったりする。むしろ今のSAML 2.0を調べようとしたらLiberty ID-
Kazuho@Cybozu Labs: HTTP 認証でログアウト処理
« WEISpub - WEIS Enabler for MovableType | メイン | 今日から始める Server-side JavaScript » 2006年02月28日 HTTP 認証でログアウト処理 今日、IPA が開催した「ウェブアプリケーション開発者向けセキュリティ実装講座」に参加してきました。 その中で、高木さんが、セッションハイジャックに強い HTTP 認証と、ログアウトができるセッション Cookie とを組み合わせることができないか、という提案をされ、その際のログアウト／セッション切れ処理をどのように行うか、という点が質疑で問題になっていました。具体的には、どのようなステートの際に、正しい username/password の組に対して 401 レスポンスを送信すべきか、という話なのですが、個人的には、そのような仕組は、あまり好ましくないと思います。 とい
RESTfullアプリケーションの簡単作成
현금카지노사이트づ「ｐｌａｙ５。ｃｏ。ｋｒ 」ぽ현금바카라사이트＼＼현금카지노사이트づ「ｐｌａｙ５。ｃｏ。ｋｒ 」ぽ현금바카라사이트＼＼현금카지노사이트づ「ｐｌａｙ５。ｃｏ。ｋｒ 」ぽ현금바카라사이트＼＼현금카지노사이트づ「ｐｌａｙ５。ｃｏ。ｋｒ 」ぽ현금바카라사이트＼＼현금카지노사이트づ「ｐｌａｙ５。ｃｏ。ｋｒ 」ぽ현금바카라사이트＼＼현금카지노사이트づ「ｐｌａｙ５。ｃｏ。ｋｒ 」ぽ현금바카라사이트＼＼현금카지노사이트づ「ｐｌａｙ５。ｃｏ。ｋｒ 」ぽ현금바카라사이트＼＼현금카지노사이트づ「ｐｌａｙ５。ｃｏ。ｋｒ 」ぽ현금바카라사이트＼＼현금카지노사이트づ「ｐｌａｙ５。ｃｏ。ｋｒ 」ぽ현금바카라사이트＼＼현금
LAPISLAZULI HILL#Hatena - AtomPPやRESTなどのAPIにおける認証のメモ
WSSE認証 Basic認証 Digest認証 ひとまずはBasic認証で充分な気がする．WSSEは消えつつあるのかな? 以下引用メモ # 2007年06月30日 miyagawa miyagawa Basicのほうがいいよ VoxのフィードはmiyagawaさんがBasic認証対応にしたみたいです。確かにWSSE認証に対応したフィードリーダーなんて聞いたこと無い。 でもたとえば記事のPOST/PUT/DELETEとかはBasic認証でやちゃっていいのかな？今作ってるサービスでも認証方法が決まらなくてscaffold_resourceで生成したAPIもPOST/PUT/DELETEはコメントアウトしてるんですよね。 Basic認証 より正確にいうと、Atom 自体に独自の認証スキームは定義せずに、既存のHTTPで利用できるBasic/Digestを使おうということだと認識しています。WSS
yohei-y:weblog: Paul Prescod の Common REST Mistakes
Paul Prescod の Common REST Mistakes の翻訳版を公開しました。 本当は今年の1月に訳してたんですが、諸般の事情で公開するまでに時間かかってしまいました。また、村田さんからたくさん助言をもらって訳文を修正してあるんですが、それでも Paul の文章は僕には難しくてあんまり読みやすい日本語にはなってません。ただ非常に含蓄のある内容ですのでぜひ原文とあわせてご覧ください。 3 Comments: At 2006年3月7日 13:40:00 JST, Unknown said... 2点質問です。 「6.セッションは関係ない。 」に「あらゆるメッセージについて自動的に HTTP 認証は行なわれる。」という記述がありますが、BASIC認証ならOKとかいう話なのでしょうか? 「クライアントアプリケーションは、リソースを使うのであってサービスを使うのではない。 したがっ
GData JavaScript のクロスドメイン通信の解析 - snippets from shinichitomita’s journal
以前の続き。JavaScriptからプライベートデータの参照、更新が出来る。Google Account Authenticationの仕組みを利用している。この前動かなかったサンプルはいつの間にか動くようになってた。 最初プロトコルは勝手にJSONPと思ってたけど、中身見てみたらIFRAME 使った fragment identifier (window.location.hashの値、URLの＃以降)による通信だった。たしかに、IEで音をONにしたらクリック音カチカチする。ちなみにfragment identifierによるクロスドメイン通信は他にdojoがライブラリとして実装しているのは知っているけど、これだけ大々的にサービスで使われてるのを見たのは初めて。もっとも、ブラウザでクロスドメイン通信を達成する方法のうち現時点でもっともマシなのはこれじゃないかという意見もある。 解析してみ
「PCからオンライン取引、ケータイで認証」－ソフトバンクBBの新発想・認証サービス
ソフトバンクBB株式会社は9月20日、PCからのWebサービス利用時の認証にケータイを鍵として利用する「SyncLock WEBアクセス用認証サービス」を発表した。技術統括 認証メディア事業戦略室長の中島啓一氏が、「同サービスはまったく新しい認証の手段だ。暗号化技術にも依存しないので、クラッカーとのいたちごっこにもならず、これまでの認証の問題を一挙に解決することが可能。本当の意味でIT革命が起こせると期待できるサービスだ」と意気込みをあらわにしながら説明を行った。 同サービスは、携帯電話を本人認証の鍵として利用する独自の認証システム「SyncLock」を利用したもの。従来、Webサービスの認証ではID・パスワードが定番として利用されている。しかし、「サービスごとに別々のアカウントを管理するのには限界がある」と中島氏が話すように、すでに個人で管理しなければならないID・パスワードの数は飽和状
OAuth 2.0 — OAuth
OAuth 2.0 OAuth 2.0 is the industry-standard protocol for authorization. OAuth 2.0 focuses on client developer simplicity while providing specific authorization flows for web applications, desktop applications, mobile phones, and living room devices. This specification and its extensions are being developed within the IETF OAuth Working Group. OAuth 2.1 is an in-progress effort to consolidate OAut
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
TechCrunch | Startup and Technology News
OpenID4U - A Web Authentication Proxy