Introduction : The Apache OpenID Module mod_auth_openid is an authentication module for the Apache 2 webserver. It handles the functions of an OpenID consumer as specified in the OpenID 2.0 specification. See the FAQ for more information. Download the current release from the the releases page. Example Most people want to see an example first: http://coop.butterfat.net/~bmuller/mod_auth_openid/ot
はてなグループの終了日を2020年1月31日(金)に決定しました 以下のエントリの通り、今年末を目処にはてなグループを終了予定である旨をお知らせしておりました。 2019年末を目処に、はてなグループの提供を終了する予定です - はてなグループ日記 このたび、正式に終了日を決定いたしましたので、以下の通りご確認ください。 終了日: 2020年1月31日(金) エクスポート希望申請期限:2020年1月31日(金) 終了日以降は、はてなグループの閲覧および投稿は行えません。日記のエクスポートが必要な方は以下の記事にしたがって手続きをしてください。 はてなグループに投稿された日記データのエクスポートについて - はてなグループ日記 ご利用のみなさまにはご迷惑をおかけいたしますが、どうぞよろしくお願いいたします。 2020-06-25 追記 はてなグループ日記のエクスポートデータは2020年2月28
と言う訳でついに来ましたね。 http://mixi.jp/openid.pl mixi OpenID << mixi Developer Center (ミクシィ デベロッパーセンター) 中の人、お疲れ様でした。 実はさっきまで mixi に行って技術的な意見交換などしてきました。mixi OpenID の技術的な側面なんかを簡単に紹介したいと思います。 ミクシィ認証 これは普通の OpenID Provider の挙動と同じです。僕のアカウントは http://mixi.jp/show_profile.pl?id=29704 なので僕の OP Local Identifier は、 https://id.mixi.jp/29704ここでお気づきの方も居るかと思いますが、OP Local Identifier 自体も https で提供されています。さて最初の html の内容を確認して
仕様 mixi OpenID は mixi 内のユーザー情報を外部サイトでの認証に使用するためのサービスです。この文章では mixi OpenID の仕様について説明します。 FAQ mixi OpenID について、よくある質問とその答えをまとめました。 mixi Platform用素材利用ガイドライン ユーザーに簡単にわかりやすくログインできるようにするために、専用ログインボタンを配布しています。また、利用ガイドラインに沿ったボタンの利用をお願いしています。 ガイドライン mixi OpenIDを導入いただくにあたってのガイドラインとなります。本記載内容に沿った対応サイトを作成いただくことで、ユーザーにメリットのあるコミュニケーションがもたらされることを望んでいます。
最近ずいぶんフィード消化してませんでした。で、久しぶりに見てみたら、こんな話がZIGOROuさんとこに。 Web+DBのOrenID特集を読みました。、教えて欲しい疑問点があります。素人なので初歩的な疑問点で申し訳ありませんが、よろしくお願い致します。 今、携帯電話の契約者固有IDのプライバシーの懸念が問題になっています。http://takagi-hiromitsu.jp/diary/20080710.html 問題点を以下に要約しますと、 a サイトで住所氏名Eメールアドレス等の個人特定情報を入力することによって、その個人特定情報と契約者固有ID(iモードID等)とが紐付けられ、ネット上での行動履歴情報が契約者固有IDを手掛かりに収集され(名寄せされ)、その収集情報と個人とが結び付けられる。 b 収集情報と個人とを結び付けた情報(以下「個人特定型ライフログ」という)が、悪徳業者の手に渡
OpenID Provider のセキュリティ対策 (1) - まずは SSL を導入!話はそれからだ - Yet Another Hackadelicの続編です。 はじめに RP が認証アサーションリクエストである checkid_setup/checkid_immediate を行う際には通常は return_to と realm を指定します。 return_to とは OP から認証アサーションレスポンスを間接通信で受け取る際に戻って来るURLの事。RP が指定しておく。 realm とは return_to のパターンをワイルドカードを使って表現する。 return_to と realm の検証 基本的に return_to の先は http://openid.art-code.org/handler であるという前提で。便宜上番号振りました。 (1) 期待通りの組合せ real
あるサービスプロバイダが、OpenID、OAuthを利用したデータの提供の両方に対応している場合、 そのどちらもRP,Consumerとして利用したいというサービスがあった場合、OpenIDのために、 エンドユーザーをOPにリダイレクト、そしてまた、データを取得するAPIを叩きたいときに、 OAuthのフローに従って、エンドユーザーがプロバイダにリダイレクトさせて認可を求めなければ なりません。 二つの異なるプロトコルで、共にエンドユーザーの承認を求める画面出すこのフローは、 エンドユーザーを混乱させるものになります。 「なんで何回も飛ばすんだ。まとめて一度に認証させればいいだろ。」ってことですね。 それを可能にするためのOpenIDの拡張仕様として提案されているのが、 OpenID OAuth Extensionのようです。 http://step2.googlecode.com/svn
■ 通信プラットフォーム研究会 傍聴録 (Google社の発言あり) 通信プラットフォーム研究会が一般公開されているのを最近になって知り、先週7日に開かれた第6回会合を傍聴してきたので、討議の様子を書き留めておく。 それまでの会合の議事録を事前に読んで行ったのだが、これほど大きな会合(たくさんの人に発言権があり、たくさんの人が傍聴するもの)とは予期していなかった。構成員だけに発言権があると思っていた(各回のヒアリング対象が「オブザーバー」として発言することもあると理解していた)が、そうではなく、「オブザーバー」(傍聴者のことではない)全員に発言権がある形式だった。「オブザーバー」の今回の出席者は、配布資料の座席表によると以下の通り。 ヤフー、モバイル・コンテンツ・フォーラム事務局、マイクロソフト、東日本旅客道、日本インターネットプロバイダー協会、テレコムサービス協会、情報通信ネットワーク産
2008/08/05 OpenID、SAML、CardSpace、3つのアイデンティティ管理の技術仕様が互いにデファクト・スタンダードの地位を争い、今後10年は“アイデンティティ三国志”の時代となってしまうのだろうか――。この問いかけに対して、それぞれ立場から専門家が意見を述べる珍しいイベントが行われた。 アイデンティティ三国志時代に突入か 7月18日、リバティ「アライアンス日本SIG主催による「第3回 Liberty Alliance 技術セミナー」がNTT武蔵野研究開発センタで開かれた。東京・JR三鷹駅からバスで約15分という、あまり便利といえない開催場所で、激しい夕立に見舞われるという悪条件にもかかわらず、120名を超える技術者が集まった。認証・アイデンティティ管理のフレームワークは近年各種WebサービスやSaaSの台頭と相まって注目されているが、OpenIDなど急速に台頭する技術や
やっと下準備終わったので書いてみる。 OpenID でのプトロコルメッセージで、認証アサーション要求*1及び応答*2でのメッセージは通常、RP-OP 間で associate 時に交換した MAC キーを持って署名を行う為、期待する相手と通信している限りは改ざんは起こりにくいと考えられます。 但し最近話題に出て来ている DNS Cache Poisoning のような攻撃を受けた場合、中間者攻撃 (man-in-the-middle attack) が成立する可能性があります。 攻撃手法の例 例えば、RP の DNS が汚染されていた場合を考えます。本来 OP であるはずのホストが悪意のある第三者のサーバーに割り当てられていた場合、その第三者のサーバーが中継を行えば、DH 鍵交換を行ってもまったく無意味で、認証データが盗まれる可能性があります。つまり、 RP から見ると OP に見えて O
高木先生の大作である日本のインターネットが終了する日を受けて、僕の日記のコメント欄にてid:futureeyeさんから質問が来ていたので、個人的な見解としての回答をしたいと思います。 名寄せの問題 a サイトで住所氏名Eメールアドレス等の個人特定情報を入力することによって、その個人特定情報と契約者固有ID(iモードID等)とが紐付けられ、ネット上での行動履歴情報が契約者固有IDを手掛かりに収集され(名寄せされ)、その収集情報と個人とが結び付けられる。 そもそも前提として携帯キャリアが確認無く契約者固有IDを任意のサービスに対して公開するという行為と、OpenIDのようにユーザの同意の下に Relying Party ( OpenID 認証を提供されるサービス ) に対して公開するのでは話のレベルが全然違います。 とは言え名寄せと言う点ではクロールして公開されている全ページを収集すればある程
第三回 Liberty Alliance 技術セミナーで=natさんの基調講演を公聴してきて、OpenID関連の動向を仕入れたのでメモ。 OPとRP間で属性情報を交換するための拡張として、SREGやAXがあるが、AXも今ひとつ普及するに至っていない。(myopenid.comとVeriSignだけ?)また、プライバシポリシーや利用規約の問題もあり、日本企業では、ユーザ属性をサードパーティに公開出来ない事も多い。 基本的に、AXとSREGの違いは、 交換可能な属性をコミュニティベースで提案&決定する属性を識別するために、プリミティブな値でなく、ネームスペースURIを使うOPに要求する属性の個数が指定可能RPがOPに対して属性の保存をする事が可能。(ただし、使われているプロバイダは知らない。) が挙げられるが、根本的な問題は、OpenIDのユーザ属性として、クレジットカード番号や電話番号などプ
後にも先にもセキュリティがメインテーマの集いでお話する事が無さそうな id:ZIGOROu です。他のスピーカが全員スーツで来る中、一人私服で来ると言う緊張感の無さ*1でしたが、実際は激しく緊張してましたw 7/5 Developers DAY – 事件は現場で起こっている……セキュリティライフサイクルとマルプラクティス | Web Application Security Forum - WASForum にて講演したスライドを公開します。 The Security of OpenID Authentication 2.0 (PDF ファイル) 話の内容ですが、 OpenID プロトコルの概要 OpenID のセキュリティ discovery association RP の詐称と return_to, realm nonce の確認 Identifier 再利用問題 Reputatio
昨日、百度株式会社さんの会場をお借りして、Identity Conference #2 がありました。 ひとり琉球大学の修士の方が沖縄からこのカンファレンスの為だけに上京すると言う豪気な方もいらっしゃいました。どう見てもRubyKaigiの裏番組なんですが非常にありがたいですね。次にまた上京したい場合は個人的にご連絡下さいね。何らかのお手伝いが出来ればと思います。 以下各プレゼンの感想などと、次回の話などです。 プレゼン 基調講演 XRI, Reputation, Trust (=natさん) 今回は忘れずにいらして下さいましたw XRI についての技術的な概要、また最近話題になっていた XRI vs URI の話にも触れ、Reputation は何故必要なのかと言うお話でした。 この資料、もう一度読みたいなー。 XRI のコンセプトは Web 中心では無く、XRI の対象としている世界に
はじめに OpenIDは、ユーザー認証および識別サービス分野に大きな変革をもたらすサービスであり、フレームワークであり、プロトコルでもあります。2004年にBrad FitzpatrickによってスタートしたOpenIDですが、今ではAOL、Google、IBM、Microsoft、VeriSign、Yahoo!などの巨大インターネット組織からサポートされるほどのフレームワークに成長しています。OpenIDは、Webサイトのための信頼性に優れたオープンな分散ユーザー認証を実現する仕組みであり、Web開発者は認証コードを書く手間から解放されます。 本稿ではOpenIDの概要と、Webサイト開発にとってのOpenIDの利点について説明します。また、OpenIDをRuby on Rails 2.0フレームワークに組み込む方法について例を挙げて説明します。必要な環境Rubyバージョン1.8.4以上
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く