Kazuho@Cybozu Labs: Web Identity Syndication (WEIS)
表の各項目について説明します。なお、以下では WEIS の仕様に準じ、リソース (データあるいは機能) を提供するウェブサイトを Provider、それを利用するウェブサイトを Consumer と呼びます。 ・スケーラビリティ Consumer が Provider 毎にサービスをカスタマイズする必要があるかどうか、を示すのがこの項目です。 flickr や 30 boxes の承認 API は自社のアプリケーションに密結合されています。また、無知な Consumer がリソースにアクセスしようとして認証を要求された場合に、どのようにして認証トークンを要求すればよいか、発見 (Discover) する仕組みを持っていません (つまり、認証 API の URL について、 Consumer が事前に知っておく必要がある) 。 したがって、flickr や 30 boxes の API は、
HTTP クライアントを作ってみよう(6) - Digest 認証編 -
Digest 認証 (ダイジェスト認証) 前ページでは Basic 認証を紹介し、セキュリティ面で問題があることを示しました。 その欠点を解消したのが Digest 認証です。 以下の URL では Digest 認証を行っています。 ブラウザから操作する分には Basic 認証と区別が付かないでしょうが、 認証の仕組みはちょっと複雑になっています。そのかわり、 ネットワーク上を流れるパケットを覗き見られても、パスワードがばれることはありません。 以下、仕組みを簡単に説明します。 「メッセージダイジェスト」の意味がよくわからなければ、暗号化のお話 (3) を参照してください (「ハッシュ」と「メッセージダイジェスト」は同じものと考えてください)。 まず、あらかじめサーバ側にパスワードの MD5 メッセージダイジェストを保存しておきます (ユーザ登録に相当)。 クライアントが Digest
OATHが目指す“信頼”の形 － ＠IT
第1回 OATHが目指す“信頼”の形 相原 敬雄 日本ベリサイン株式会社 マーケティング部 課長 2006/1/20 インターネットの出現により、過去の地政学的な障壁はここ数年の間に消え失せ、PtoP通信や、これまで考えられなかったような情報交換が可能になりました。インターネット、つまり“ネットワークのネットワーク”によって世界中の人々にもたらされた変化の顕著な例としては、Eコマースとメールの2つが挙げられます。 同時に、残念なことではありますが、ネットワークのユビキタス性や柔軟性によって、セキュリティ面の懸念が生じているのも現実であり、インターネットは危険な場所になりつつあります。 インターネットの発展を可能にした背景の技術的キーワードとして「オープン」「標準化」および「相互運用性」が挙げられます。しかし、認証システムおよび関連技術では「オープン」「標準化」および「相互運用性」はいまだに
Flickr の認証API - naoyaのはてなダイアリー
認証API をどうするか、ということで数名のスタッフであれこれ話ながらやってます。 まず、はてなの認証APIを使って何ができるといいのかというところですが、はてなラボをオープンしたときにいただいた意見などを見ると、「はてなのAPIで認証付きのをセキュアに利用するための API」というより「サードパーティのアプリケーションではてなIDでユーザーを識別できるためのAPI」の方が求められているという風に思いました。 具体的には、新規にユーザーを識別する必要のあるアプリケーション、例えば掲示板などを作るとして、その掲示板のユーザーを一意に識別する方法としてはてなIDを使いたい、そのIDが本当にその人のものであるかどうかをはてなが保証する、その保証を問い合わせるための API ですね。その掲示板でログインして何かを書き込むと id:naoya、と表示されると。 この手の認証APIを提供しているサービ
naoyaのはてなダイアリー - 認証API
日本でも多くのWeb APIが公開されているのは喜ばしいことだけど、どれも認証に本気で取り組んでない感じがする。Open Dataはもう当たり前。あちらのほうでは更新できるWeb APIも当たり前になりつつある。Flickr APIの認証はアプリ作成がちょっと面倒になる場合がある（僕のMTプラグインとか）が、とりあえずそれでもいいし、TypekeyでもOpenIDでも試してみる価値はあるだろう。はてなやmixiは、そのサービスでのアイデンティティがそのまま他のサービス上でも通用することもあるわけで、認証APIがあればサービスの価値が大いに高まると思う。 ちょうど今朝認証APIをそろそろ作ろうかという話をして、プロジェクトを立ち上げました。ラボも作ったことだし、そろそろはてなIDを使ってアプリケーションが作れるようにしたいなという意志がありまして。 過去にもはてなのサービスを Hack した
2006年は認証APIの年
Webカレンダーの30Boxesが「出す」と宣言していたAPIの一端を公開した。まだイベントの作成と更新が公開されていないが、それが出れば手元のツールと同期するプログラムとか簡単に書けそうだ。 Google、Amazon、eBayで始まったWeb APIの大きな流れは、当初の読み取り専用データのWeb公開（Open Data!）を経て、Flickr APIとその仲間たちやAtom PPのような更新できるAPI（をSPIと呼んだこともあったっけ）へと歩を進めつつある。 更新できるAPIで重要なのは、認証機能だ。30Boxesも、カレンダーにデータを追加することを念頭においているわけだから当然だが、最初から認証機能が用意されている。こんなAPI呼び出しでユーザーの承認を受けることができる。Flickrとその仲間たちも同じような仕組みでユーザーがアプリへ承認を与えることができる。Amazon W
Kazuho@Cybozu Labs: RSS Feed と認証
« mod_webdev | メイン | フィードビジネス・カンファレンス リンク集 » 2005年12月08日 RSS Feed と認証 本日 (12月8日) フィードビジネス・カンファレンス (FBS カンファレンス) で RSS Feed の拡張について話しました（資料は後ほどカンファレンスのページで公開されると思います）。カンファレンスでは Podcasting を始めとするさまざまな RSS の拡張を紹介したのですが、本エントリでは、その中で説明した RSS Personalization について書きたいと思います。 I. 背景 RSS は今日、現在ブログやニュースといった、主に公開情報を配信するために使われています。しかし今後は、Ｅコマースや社内ソフトウェア、SNS といった認証やパーソナライゼーションが必要な分野でも使われていくだろうと考えられます。 現時点でも Basic
Tomcatでダイジェスト認証を使う
Tomcatには、基本認証やダイジェスト認証などの、HTTPによるアクセス認証の機能が組み込まれています。Webアプリケーションに本格的な認証を付けたい場合には、Tomcatのフォーム認証や自前で用意した認証機構などを使う必要がありますが、簡易的にアクセス制限を施したい場合などは、これらのHTTPによる認証で事足りるでしょう。 そのうち基本認証は、簡単なのでよく利用されます。基本認証では、ユーザーが入力したパスワードは、BASE64という方法で符号化されてネットワーク上を流れます。このBASE64符号化は、そもそも暗号化のための方法ではなく、符号化のアルゴリズムを知っているものならば、誰でも簡単に解読できてしまうものです。そのため、認証時の通信を傍受されると、パスワードが簡単に取得されてしまい、基本的に安全ではありません。 通信経路の秘密性を保つには、SSL（Server Socket L
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
http://plus.ric.co.jp/wireless/wl003_05_0504.html