このエントリはmitani1207の日記の返信です。 OpenIDによる認証を受け入れるということは、自分のサイトのIDとパスワードの管理を外部サイトに委託することになる。 外部サイトがパスワードをどう管理しているかはわからない。もしかしたら、生でDBに保存してあって、管理者がSELECT * FROM USER_TABLEとかで簡単にとれちゃったりするかもしれない。これは課金情報やプライベートなデータを扱っているサイトにとっては心配だ。 この前提は同感ですね。 OP(IdP)がどのような管理を行っているかなんて、利用者あるいはRP(Consumer)からは判断のしようが無いですからね。 でこの辺りの話は手前味噌ですが、@ITでのOpenIDの連載で書かせて頂きました。 OpenIDをとりまくセキュリティ上の脅威とその対策 (3/3):OpenIDの仕様と技術(4) - @IT にある、「
_ OpenID に向いている認証と向いてない認証 [openid] ZIGOROu さんのとこで,OpenID の使い道について面白い議論がされてい ました. Re:本当は怖いOpenIDによる認証 - Yet Another Hackadelic まず大前提として個人情報等、センシティブなデータを取り扱うサイトは 必ず会員登録は行うべきで、認証、認可はRPのIdentifierに対して与えら れるべきです。 RP (Consumer) のユーザID で認証するのであれば,OpenID を無理に使わ なくても良さそうな気がします.この後,ZIGOROu さんのエントリではい くつかの解決策が提案されているのですが,一歩戻って OpenID の使いど ころについて考えてみることにしました. # これから書くことって当たり前のことな気がするけど,そういうことで # も書いて確認できるのがブロ
id:teahutさん*1が早速反応してくれたので、さらに被せちゃいます。 たけまる / OpenID に向いている認証と向いてない認証 の返信です。 OpenIDの使いどころについての分類 Sreg*2やAX*3の存在も含めると、OpenIDの持つ主要な機能は二つで、 IDの認証 IDに関連するメタデータの取得・設定 だと思います。 で前のエントリや、たけまるさんのエントリでは認証と言う機能が適用されるシーンについての話だったかと思います。 認証について たけまるさんはざっくり言えば、ヘビーな用途*4とライトな用途*5に分けてるのかなと思いました。これは分かりやすい分類ですね。 現時点の OpenID は,2. を対象としているのでしょう.サービスの都合でユーザのトラッキングを行いたい. でも,わざわざ新規登録するのは敷居が高くて,多くの人に使ってもらえない. じゃあ,OpenID でユ
This shop will be powered by Are you the store owner? Log in here
あまり良く分かっていなかったシングルサインオン(以下SSO)についてのまとめ。 そもそもSSOとは、IT用語辞典によると ユーザが一度認証を受けるだけで、許可されているすべての機能を利用できるようになるシステム。 のことだ。つまり、 図1のようにアプリが1つの場合には不要である。また 図2のようにアプリが複数でも認証情報(Session)を共有する場合には、SSOサーバは必要ない。各アプリの依存度が高い場合や、負荷分散のための複数プロセス構成のケースではこれで充分。そもそもRailsを使うのならSessionの内容はCookieのなかだし(デフォルトでは)。 独立性の高い各アプリの間で認証情報を共有したい場合にSSOサーバは初めて有効となる。 ここで認証画面を各アプリで持つことも可能であるが、SSOサーバに任せた方が実装の手間も省けるし、セキュリティ的にもパスワードを取得するサーバが一箇所
マクニカネットワークスは2012年3月26日、社内システムだけでなくSaaSを含めてシングルサインオン(SSO)できるようにするサーバーソフト「PingFederate」を発表した。SAMLのフェデレーションなど、SSOにおけるID連携の仕組みを使って、SaaSのID管理負荷を低減する。4月2日に出荷する。価格は、接続するWebシステム当たり400万円(税別)。開発会社は、米Ping Identity。 PingFederateは、SSOソフトである。社内のActive DirectoryのようなID管理/ユーザー認証システムに対してログインするだけで、SaaSを含めた各種のWebアプリケーションに対する個別のログイン手続きを省略できる。ユーザー認証システムとWebアプリケーション間でやり取りするID連携情報としては、SAMLやWS-Federationなど、各種の業界標準仕様を利用できる
{今年|今月|今週|今日}も何%過ぎました ゆく河の流れは絶えずして、しかももとの水にあらず (鴨長明:荘子) FESTINA LENTE ゆっくり急げ (ローマ帝国初代皇帝 アウグストゥス) 立派にできたのであれば、それは十分早くできたことになる (ローマ帝国初代皇帝 アウグストゥス) 海豹日記 へようこそ このサイトは、個人的な覚書を残しておくサイトです 自分は、よくこんなことをします 何かの困りごとや興味の赴くままに、いろいろ調べる 数か月後に、そのことを忘れてしまって、同じことについていろいろ調べる。しかし、そのうち、数か月前の自分が、同じことを同じように調べていたことに気づく それは不毛なので、覚書を残しておこうというわけです (主人公のアリスに掴まれて、チェス盤のはるかかなたまで持ち上げられたことのあるチェスの王さまが、当時のこと思い出し) 王さま「あの瞬間の恐怖といったら、わ
近年、企業のニーズとしてシングルサインオンの導入がどんどん増えつつある。 開発者にとってはコストを抑えながらお客様のニーズをどう充たせるか非常に悩ましいところである。 そういう場合、open source solutionsならコスト1)の面で有利なので、一応検討する価値はあると思う。 主なopen source solutionsには次のものがある。
今回から始まった「ゼロから学ぶOAuth」。全4回の特集にて、これからのWebサービスを開発する上で不可欠な技術「OAuth」について取り上げます。初回は、OAuthの概念について取り上げます。 はじめに はじめまして、iKnow!改めsmart.fmの真武です。現在smart.fmでは、OAuthやOpenID、OpenSocial、Semantic WebやActivity Streamなどといった新しい技術の導入を積極的に行いサイトを活性化させるとともに、smart.fm APIを通じて我々の技術を外部のデベロッパの方々にも提供しています。 smart.fmは日本最大のOpenID Relying Partyであるだけでなく、国内では数少ないOAuth Consumer(後述)およびOAuth Service Provider(後述)を兼ねるサービスとなっています。こういった背景
「おーおーっすっ!」 てなこって、TwitterのAPIのBASIC認証も6月末に終了してOAuth/xAuthに移行するというこの時期に、あらためてOAuthについて勉強してみたんですのよ? OAuth認証を利用するライブラリは各言語で出そろってきてるのでそれを使えばいんじゃまいか? というと話が終わるので、じゃあそのライブラリの中身はなにやってんのよってことを、OAuthするScalaのライブラリ作りながら調べたことをまとめてみました。 間違っているところもあると思うのでツッコミ歓迎です>< OAuthってそもそもなんなの? ものすごくざっくりというと「API利用側が、ユーザ認証をAPI提供サービス側にやってもらうための仕様」って感じでしょうか? BASIC認証の場合、API利用側が認証に必要なアカウントやパスワードを預かる必要があるわけです。悪意のあるAPI利用側が「なんとかメーカー
にほんブログ村 名前:色人 年齢:0x22 誕生日:9 性別:男 職業:元JOCV (青年海外協力隊) 元期間限定SE。コンピュータ/物理/数学/AKB (09/18) サイバー脅威組織(APTグループ) (09/14)2018年上半期のサイバー攻撃のトレンド (09/13)情報処理推進機構(IPA)の資格試験のおすすめ (01/04)植物たち (01/03)初詣 (01/02)【AKBファンが知るべき47のこと】 その45: 会いに行ける (01/01)🐶 2018年 🐕 新年 🐶 (12/31)2017年のおわり (09/13)東北巡礼 (08/14)道路で出会うとちょっとびっくりする生物 (07/12)BONSAI (07/10)夏のオクトーバーフェスト (07/09)沖縄の景色 (05/26)沖縄最終日、もっといたい (05/23)宮古島ダイビング ポアンカレ予想 (ジョー
1. はじめに クラウドを利用する企業や大学が多くなってきていますが、クラウドの導入には、まだ多くの課題があります。その課題の一つとして、クラウドへのシングルサインオン(以下、クラウドとの認証連携)があります。この記事では、クラウドとの認証連携の概要を説明し、この仕組みを社内(大学の場合は学内)に導入する際に利用されているSAMLの技術について具体的な例を用いて解説します。 2. クラウドとの認証連携 ここではクラウドとして一般的に利用されているsalesforceとGoogle Appsについて説明します。 2.1 一般的なクラウドへのログイン 通常、下図のように、ユーザーがsalesforceやGoogle Appsを使用には、それぞれで表示されるログイン画面にユーザーIDとパスワードを入力する必要があります。 2.2 クラウドとの認証連携 これとは別に、自分が所属する社内ポータルなど
日本ヒューレット・パッカード株式会社 テクノロジーサービス事業統括 テクノロジーコンサルティング統括本部 セキュリティソリューション本部 ビジネス開発 担当部長 榎本 司氏 従来,多くの企業では,それぞれの部門や業務ごとにシステムを構築していった結果,部分最適なシステムが林立している。これによりITリソースは複雑化し,管理コストの増大やセキュリティ上のリスクを招いている。これらは,クラウド環境ではさらに大きな問題となると、HPセキュリティソリューション本部の榎本司氏は警鐘を鳴らす。 「とくに,アプリケーションの認証処理がサイロ化したままだと,様々な問題が顕在化するでしょう」。 アプリケーションごとに認証システムを作りこんでいる企業は多いが,これでは,業務や人的システムの変更のたびに認証部分の改修の手間がかかり,新サービスの展開にも時間がかかる。セキュリティの管理業務が増え,管理
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く