はてなキーワード: SSOとは
B拠点のルーターまでは到達出来るけど NAS に行けない＆再起動抜き差しでたまに復活するなら、
LANケーブルの接触不良、HUB や NAS のポートの不調、機器の過熱や電源の不安定さの可能性がなんとなく高そうやね
～～～～～～ やるべきことはすでに確認済み／なんかよくわからなかった場合 ～～～～～～
あと、やっぱケチらんで、M365 の SharePoint か GoogleDrive を使った方がええと思うやで。社内のファイルサーバーとかの面倒を見んでええし
それから、もし無線LANに切替未なら無線LANに切り替えた方がええで。ユーザーに勝手に機器を生やされないし（予算があればだが）
更なる理想は、もし EntraID (AAD)＋Intune に以降がまだなら、この機会に移行して、 無線LAN を SSO認証と組み合わせて、
要件満たすため・社内政治的な理由でピンポイントで別のところ使う＋併用はあっても、
ゼロトラストセキュリティは、「信頼せず、常に検証する」という原則に基づいています。主な特徴として、常時の認証と承認、最小権限アクセス、アクセスの継続的な監視があります。以下の技術やソリューションを組み合わせることで、包括的なゼロトラストセキュリティモデルを構築できます。
1. Microsoft Entra ID（旧Azure AD）：
3. 多要素認証（MFA）：
1. 暗号化：
ITエンジニアの業界では資格をとってもなんの意味もないとよく言われる。
あるITエンジニア(インフラ〜バックエンド系)おじさんもその原理主義者のような人でIT系の資格取得をバカにしていた。そんな暇があったら個人開発の一つでもすればいい。資格を持ってるなんてむしろバカをアピールすることだという言いようだった。
しかしある時、おじさんと会話しているとSSO（シングルサインオン）を知らなかった。またある時は、AESが共通鍵暗号の規格だということを知らなかった。どれもAPやベンダー資格の勉強をしてればよく目にするもののはずだ。
その別の増田だけど、ほとんどの人にとって必要性がないからじゃないの？あとはSSOが使えないサイトを使うことが多いから？
まず、SSOを受け入れるところでtwitterとかGoogleとかFacebookとか出てきても、知識がないならナニコレ怖いと思いそう。
あと、現状IDやパスワードの管理に困ってなかったらわざわざSSOを有効にする面倒くさい手順を踏まないのではないかと思ったりもする。
今時のブラウザはIDとパスワードを覚えてくれたりするから、わざわざSSOにするというモチベーションは生まれないと思う。
個人的にはtwo factorを使っていないような銀行とか証券会社とかはSSOを受け入れるようにして、FIDO U2Fを使えるところで認証して、SSOで使えたほうが安全なんじゃないの？と思うけれど、現行法でそれって許されるの？
今のところ、なるべくSSOを使わないようにしてる。
パスワードはパスワードマネージャーで１サービスごとに管理してる。
でも最近のSSOの流れに、ホントにこれでいいのか疑問に思ってきた。
だってSSO提供側のTwitterやGoogleに比べれば大抵のサービスの認証は突破しやすいし。
シングルサインオンの名のとおり、SSO提供サービスにログインしてればそのままそのサービスもログインできるんだし。
でも自分のTwitterアカウントを他のサービスに知られるとか嫌なんだよなあ。
あと複数サービスのSSOに対応してる時どれで認証すれば良いのか分からなくなっちゃうし。
みんなどうしてんのかなあ。
すでに学生でもないのになぜこの件について書いているか自分でも分からないが、例の穏便でない大学教授の発言にブーストされた感がある。
まず前提として、ID/パスワードを用いてスクレイピングを行うサービスそのものは、特殊というほどではない。そのようなサービスはすでにいくつも存在するし、最も有名なところでは口座アグリゲーションサービス（MoneyForward等）だ。彼らは業としてそのようなサービスをおこなっている。セキュリティのこと少しでもわかる人間ならそんなサービスやらない、というほどでもない。ただし、セキュリティが分かる人間であればあるほど慎重になる、というのは確かではある。通常ID/パスワードを渡すということは、全権委任とおなじだ。また、ログイン後の行動について、自分がやったか第三者がやったか、全く判別できない状況になる。さらに通常のWebセッションと同等だとすると、パスワードリセットから完全なアカウント乗っ取りまであり得る。つまり、サービス事業者に対してよほど強い信頼関係がなければ厳しい、ということになる。
クラウド上で動いているかスマホ上で動いているか、という話は、それほどは重要ではない。クラウドにしろスマホアプリにしろ、すべてサービス事業者側の組んだプログラムの意図に従って動くものであることは確かだからだ。
ただしクラウド上ではユーザが想定していない動作を行っているのかどうかという検証しにくいという問題があるとはいえる。とはいえユーザが予め意図した行動から外れることをしてないのであれば、クラウドからのアクセスでも別にそれは問題ないわけで、その点で、Orario側の主張である「スマホで動かしているのだから」という主張は、ちょっと見当はずれではある。
なお、ユーザインタラクションを介さない自動的なアクセス自体がサービス要件に含まれる場合、スマホでは厳しいためクラウドにアクセス主体が置かれる、というのは、まああり得る。口座アグリゲーションはその典型的なものだろう。Orarioの場合は、たぶんその必要はないのだと思う。
正規の手段として学認があるのになぜしない？という主張は、マジでひどいと思う。普通に考えて、ぼっと出の１ベンチャーがトラストサークルに加えてもらえると思っているのか。このような主張は、Google/Facebookレベルに自由にAPIクライアントの登録ができるようになっていて、初めて言えるものだろう。通常は、世に受け入れられるサービスが出て初めて実行力を認めてもらえる、にわとりたまごの話ではないのか。そもそも、学認のShibboleth仕様で、そのような履修情報のやりとりがそもそもできるようになっているのか疑わしい。ホントはSSOできるだけではないのか？
大学側にお伺いを立てるべき、という筋論は、そりゃそうかもしれないけど、やっぱりにわとりたまごだと思う。ビジネスの筋論っていうやつは、内輪だけの論理になっている場合が多いし、正直ステークホルダーは既得権益側だったりするわけで、話が通じるとは思えない。そのようなものを破壊していくのは常に外部からだろうし、それを単なる破壊行為ではなくDisruptionにできるのは唯一ユーザからの支持であるわけだけど、Orarioは最低限そこはできていたようにもみえる。例の教授はどうも内側のメンバーの感じがひしひしと出ており、傍目から見ると、そりゃそのポジションじゃあね感が強い。
事業モデルがわからないから怪しい、事業が成り立つとしたら収集したデータの第三者への販売ぐらいしかないはずだ、という主張は、気持ちはわかるものの論理として弱い。怪しいサービスに預けるな、というのは、意見の表明ではあるかもしれないが、普遍的に怪しさを証明するには根拠が足りていない。利用規約レベルではまだなんとでもいえる。逆に言うと、Orario側は、そういう色が少しでもあったのでは？と思わせるような内容を否定してさえいけば、その点では勝てるが、やっぱりそこは何らかの形で検討して行きたかったのでは、とも思えるので、そういう将来の自分たちを制限することはことはあまりやりたくないだろうなとは思う。
結論を言うと、とりあえず大学側はもうすこしトーンを落としてほしい。このままではFUDだといわれても仕方ない。単位云々の脅しは傲慢以外の何物でもない。少なくとも卒業生にとってそのような大学にいたことを恥じるレベルである。嫌なのは分かるが、銀行とかだってそうだったはずだ。もうすこし長い目で見てあげられないのか。ID/パスワードを預けることのユーザへの注意喚起は、もちろん正当だが、それを認識して預けていることについてとやかく言うことは得策でない。
そして、Orario側は、自分たちがやっているサービスの説明に少し時間を割いてもいいと思う。特に何をどのように取得しているのか、明確にすることは重要だ。大半のユーザたちはそういうこと気にしないとしても、自分たち自身が自分たちのサービスを定義するのに役に立つし、今はEvilでなかったとしてもいつかEvilになってしまうのを防ぐという意味合いもある。面倒かもしれないが、取得範囲を明確にすることは信頼を得るということであり、最終的にユーザの獲得に寄与するだろう。
anond:20160426124418 と anond:20160426145507 の続きだゾ。てか長えよ
(略: トークンが定期的に期限切れになるので可用性が下がる。たとえばビデオカメラから複数の動画をアップロードしている途中で切れたらムキーってなる。再認証して途中からできるのもそれはそれで CSRF の温床。AFCP のような場合は期限切れがあってはならないので、パスワード等を預かる認証プロキシの SaaS アプリを筆者は作った。好評だったが、これはもちろん本来あるべきでない欠陥のexploitのはず。)
(略: 個人ユーザ向けのAPI設計ばかりで、雇用者や上司がアカウントを管理するという観点がない。SAMLでは普通にできるのに、OAuthとなるとセキュリティ的に云々と言って拒むサービスばかり。別のUIで既にできてることをAPIにしても意味がない。これまでできなかったことをAPIで可能にするのではなく、単なるシングルサインオンでよければ他にある。実際Googleは個人向けにはOAuthを活用しているが、Google Apps for BusinessはOAuth以外のシステムを使っている。)
(略: 主要な設計ミスは、外部サービスすべてを同等に疑うところ。管理者が各サービスの信用性を判断して権限を調節できるようにしないところ。これまでどれほど多くの製品がOAuthの面倒さのために失敗してきたことか。)
ここまでで「普通の実装における」OAuth がまったくおかしいということはわかりましたが、OAuth が実際うまくいくのはどういうときでしょうか。
初期の OAuth 規格および概念におおよそ付き従っているシステムは一般的に言って、新しい規格ベースのよりもセキュアで、マシです。OAuth 1.0 の実装がすべてセキュアだというのではありませんが、たいてい問題は少ないです。こうしたシステムは通常、次のふたつのアプローチのどちらかに従っています:
とはいえ、このように設計されている OAuth ベースのシステムはごくごく希少で、しかも一般的にこうしたシステムは、他のところで使われている OAuth とは似ても似つかぬものです。OAuth 1.0 規格の方に寄って頑張っていますが、公式には 1.0 は非推奨ですから、こうしたアプローチを使っているシステムはそのうち「アップデート」されて OAuth 2.0 の概念や追加機能すべてを加えて再構築され、セキュリティやユーザビリティをだめにしてしまうことになります。これこそ筆者があらゆる OAuth ベースのものを見逃したくない理由です。もっと古く、もっと機能的な形式の OAuth を使っていても、システムに「改善」が必要だという素敵な考えを管理者のだれかが閃いて台無しにしてしまうからです。ご迷惑をおかけしてすみませんと言うぐらいなら、まったく別のものを使うほうが良いですよね。
他に手はないかと探すとき、人々はよく他の「フレームワーク」にはどんなものがあるかを知ろうとします。しかし、考え抜かれたセキュアな設計を実現するためには必ずしもフレームワークが必要というわけではありません。現状、OAuth とはどのようなものかについての意見はサービスごとに異なっていますので、承認の具体的な動作の仕組みもまったく一定ではありません。そんな中でフレームワークを探しまわるのは、簡単にできることをいたずらに複雑化しているだけのことが多いです。唯一ほんとうに難しい要素、しっかりした規格の必要な要素は、使用する鍵パラメータの改竄を防ぐため変数に署名する方法だけであり、この点に関して、ほとんどの OAuth ベースの実装は一切何もしてくれません。
ウェブサービスの最大手である Amazon は、世界中の企業にサービスを提供する一流プロバイダで、合計 30% 以上という途方もない市場シェアは他者を圧倒しています。Amazon のアプローチは、自分でアプリの認証情報を生成できるコントロールパネルへのアクセスを、すべてのアカウントおよびアカウント管理者に提供することです。この認証情報で、どの Amazon サービスで作業できるか、そのサービスでどの操作を実行できるか、どの権限で作業しなければいけないかを指定できます。この認証情報は必要に応じて「アカウントホルダ」の人が破棄することもできます。
Amazon の API における認証や承認技術には、本質的に制限が多く潜在的に危険性のあるリダイレクトを一切必要としません。Amazon のプロトコルで認証情報は、直接送ることは一切なく、データの署名に使うのであって、これでブラウザを通してパラメータを送る必要のあるときにも改竄不可能にすることができるのです。
Amazon の設計はアカウントの利用状況を API の利用まで適切に把握できますし、API の認証も承認もすべて Amazon 側からスタートし、その際のアプリ認証情報も「Amazon の」コントロールパネルから生成されます。この認証情報はその後、いかなるトークン交換システムも使わず直接 API プロセスで使われます。この設計なら「普通の実装における」OAuth が達成している真のセキュリティ目標をすべて達成し、かつ前述したセキュリティ上およびユーザビリティ上の問題をすべて回避しています。
ひとつ言及せざるをえない短所は、Amazon の権限システムが幾分わかりにくく、あまりユーザに優しくないということです。ただし、このことは何故かほとんどのコントロールパネルにも言えることで、いずれにせよ UI 設計の問題であって、承認プロセス自体の失点ではありません。さらに、Amazon のコントロールパネルはかなりキビキビ使えて、それ自体の API でも使えます。この点たとえば Google の場合のように、筆者の知る限りメタ API もなく、何をするにも何十もの手順が必要なのとは大違いです。
Amazon の認証および承認メソッドは他のサービスプロバイダにも幾つかコピーされています。Google 自身も企業向け製品の一部でこれを利用できるようにしています。Google 自身、純粋な OAuth 設計は企業サービスに向いていないことを認めており、企業サービスには JSON Web Tokens (JWT) の利用を推奨しています。
JWT はサービス間の SSO や API 利用を可能にする規格です。多くの点で JWT は SAML に似ていますが、SAML はややこしくて、XML Security (名前と違って、まったくセキュアではない) の上に構築され、API 利用に向いていないのに比べ、JWT は SAML の主要な目標を、単純かつ使いやすい方法で一切の面倒なく達成しています。HMAC 実装をひとつ用意し、JSON の構築と解析の方法を知っておけば JWT は使えます。既製品をお求めでしたら、膨大な JWT ライブラリが既に存在していますよ。
ただ Google の場合、典型的な JWT 利用法よりも高度で、HMAC のかわりに、もっと高度ですがこの分野では人気の低い RSA デジタル署名を利用するよう要求しています。Google のコントロールパネルではアカウント管理者が自分の企業サービス用に新しい鍵ペアを生成でき、API ログインを署名するために使う秘密鍵をダウンロードできます。こちらのほうが HMAC よりセキュリティは高いですが、Google はプロセス全体を本当に無駄に複雑化しています。コントロールパネルをしょっちゅう完全に再設計して、前と同じことをしたいのに使い方が違っていて混乱する点は言うまでもありません。JWT 利用の実例が必要なら他をあたるようお勧めします。
他に使われている技術は、サードパーティがどんな権限を必要としているかをある種の XML や JSON ファイルで定義してウェブサイトに送信できるようにするサービスのものです。ユーザがあるページを自分のアカウントで訪問し、ファイルの URL (あるいは中身) をそこに貼り付けると、その外部サービスあるいはアプリが求めている権限の一覧やそこに含まれる説明などが表示されるようになっています。それを見て認可したいと思うユーザは、認証情報を生成してそのサードパーティのアプリあるいはサービスに貼り付けます。ユーザは後で無効にしたくなったら認証情報を破棄することができます。これも、開発者におかしな負担を強いることなく、すべてのアカウントに API サービスがあり、権限管理を備え、サービス自体からフローが始まる、実にセキュアな設計です。
承認管理のためにサービス側から提供してもらう必要が本当にあるのは、適切な役職 (管理者やアカウント所有者など) を持つユーザが自分に割り当てられた権限や (望むなら) 期限を持つ認証情報を API 利用のために生成できる何らかのパネルだけです。こうした認証情報はその後、お好みのセキュアな認証システムを通して利用することができます。たとえば HTTP Basic Authentication over HTTPS のような単純なもの、これは事実上どの HTTP ライブラリにも入っていますし、HTTP Digest Authentication、これはもっとセキュアでありながらほとんどの良質なライブラリでサポートされていますし、その他 HMAC, RSA, 楕円関数など認証情報をネットに通す必要のない暗号学的テクノロジーを活用した認証プログラムに基づくものなら何でも使えます。特に HMAC は、承認や認証を実装するほとんどすべての人 (Amazon や、一部の OAuth 実装も含む) によって既に使われています。
こういった種々の実績あるテクニックは、セキュアなプラットフォームを作るために CSRF 対策など複数のフレームワーク同士の相性を勉強する必要があるという重荷を軽くしてくれますし、一般的に、既存アーキテクチャにワンタッチで装着できるようなモジュール化の実装が可能です。ユーザやアプリの認証情報が盗まれる可能性をなくしてくれます。ややこしい CSPRNG を常に使用する必要もありません。このようなシステムは OAuth の生まれるずっと前から存在しており、現在でも一般的です。OAuth は、ユーザの認証情報を要求したり他に弱点があったりするような一部の劣悪な設計のシステムよりはセキュリティが良いかもしれませんが、既にある真の設計を置き換えるものではありません。OAuth が解決すると主張する問題点は実のところ、既存の良く設計されたシステムには存在していませんし、「普通の実装における」OAuth は実のところ、解決すると主張する問題の多くを招き入れるばかりか、最初は存在していなかった問題まで生じさせています。宣伝文句と違って、OAuth にすれば自然と驚くほどセキュアになるというわけではなく、むしろ数々の短所や実装の困難さを考えれば、他の考え抜かれた選択肢のほうがはるかに優れています。
これからサービス設計をして API アクセスを提供することになっている方はどうか、ご自分が実現しようとなさっているのが何なのかを本当に考えてください。他の人がやっていることをコピーするだけで済ませたり宣伝を丸呑みしたりしないでください。どうしてもコピーしなければいけないなら、Amazon (これが最善です) や Rackspace, IBM SoftLayer, Linode, VULTR, Zoho, Zoom ほか、API の素直で健全な認証システムを構築する方法について現時点で多少なりとも理解のあるところをコピーするようにしてください。
2016 年 4月 Insane Coder