「sso」を含む日記 RSS

はてなキーワード: ssoとは

2023-03-09

資格バカにするおじさんエンジニア

ITエンジニア業界では資格をとってもなんの意味もないとよく言われる。

あるITエンジニア(インフラバックエンド系)おじさんもその原理主義者のような人でIT系の資格取得をバカにしていた。そんな暇があったら個人開発の一つでもすればいい。資格を持ってるなんてむしろバカアピールすることだという言いようだった。

しかしある時、おじさんと会話しているとSSOシングルサインオン)を知らなかった。またある時は、AES共通鍵暗号の規格だということを知らなかった。どれもAPベンダー資格勉強をしてればよく目にするもののはずだ。

資格はそれ単体では意味がないというだけで、実践資格の両輪で役に立つんだというならわかるけれど。

資格自体バカにするおじさんはその程度なんだなと思った。

2022-06-17

zoomさんへ

zoomワンタイムパスワードを求めてくるのホントやめて欲ください。

管理サイトサインインでワンタイムパスワードを求めてくるのはいいけど、

アプリからサインインで要求するのはホントやめて、しんどい

https://anond.hatelabo.jp/20220617194242

会社情シスに「ZoomWeb版だけにしてSSOしたらどうか」って伝えてごらん

一目置かれるよ

2022-03-16

1PassWordって便利なん?

家族がいないか分からんのだが、子供家族とサブスクが共有できるメリットがあるらしい。

仕組みとしてはCookieなのか、SSOなのか、デバイス証明書なのか?

おっさんなんでWeb技術わからん。だれか教えて。

https://tart.co.jp/1password-setting/

2021-10-16

クラウド会計どれにする?って話題

別にFreeeeeでもマネーフォワードでもいいんだけど、

前者は社員画像中国人くさかったので却下

後者は地味にWebアプリが分かれてて(会計給与・社保など)

同じ会社なのにSSOみたいな連携挙動必要だったり、UIが使いにくくかたのと、

あとページロードが地味に重かった。有料なのに。

ってことで弥生クラウドかなと思ってる。

なんか意見ある?

2021-09-26

キャプテン・テニールSAML認証シブいねェ・・・まったくオタクしぶいぜ」

しかローカルAD認証SSO簡単じゃねー・・・

数百万ものクソ高い認証基盤はすでに企業から見限られているぜ

2021-07-12

anond:20210712082259

一気にいった=オンプレ廃止しとるよん

ゆうても数か月は残したけどね

業務アプリVPSに移行してAADでSSOログインさせてる

まあ100名以下の小さい会社から独力でできたんだけどね

そこそこの規模なら大変やろうね

2021-04-14

anond:20210414004942

毎回アカウント発行するよりSSO運用する方が絶対に面倒だと思う、共用サーバーがそんなにあるとも思えないし使う人にroot投げて自分管理させれば良いのに

全員のアクセス必要ものがあるなら手作業せずに全員のアカウントざっと登録して初期パス入れてメール発射するスクリプトくらいPythonかなんかで書いておくと良い

2019-07-01

anond:20190630232246

その別の増田だけど、ほとんどの人にとって必要性がないからじゃないの?あとはSSOが使えないサイトを使うことが多いから?

まず、SSOを受け入れるところでtwitterとかGoogleとかFacebookとか出てきても、知識がないならナニコレ怖いと思いそう。

あと、現状IDパスワード管理に困ってなかったらわざわざSSO有効にする面倒くさい手順を踏まないのではないかと思ったりもする。

今時のブラウザIDパスワードを覚えてくれたりするから、わざわざSSOにするというモチベーションは生まれないと思う。

個人的にはtwo factorを使っていないような銀行とか証券会社とかはSSOを受け入れるようにして、FIDO U2Fを使えるところで認証して、SSOで使えたほうが安全なんじゃないの?と思うけれど、現行法でそれって許されるの?

2019-06-30

anond:20190630222912

別の増田が言うようにOAuthじゃなくSSOだというのはその通りで、SSOという名前を知らない人の意見も知りたかたからあえて使わなかったんだがそんな用語の事はどうでも良くて、俺が知りたいのは個々人が使わない理由なのよね。

お宅が言うそSNSを信用するかというのも一つの材料だけど、他にもログインするときにどのSNSアカウントSSOするか忘れるのが嫌だとか、ちょっとサービス使うのにいちいちSSO個人情報の一部を知らせないといけないとか(これはApple場合ほぼ解決されるが)、そういう理由があれば聞きたいのよねってのが背景。

anond:20190630222912

本気で言っているのか、ぼけているのか知らないが、言わないよ!!!

OAuth2じゃなくて、SSO (シングルサインオン) だろ。

OAuth2はシングルサインオン欠点を補うために作られたプロトコルで、まさに増田問題にしている点を解決するために作られたんだよ。

2018-05-24

SSOシングルサインオン)ってみんな使ってる?

今のところ、なるべくSSOを使わないようにしてる。

パスワードパスワードマネージャーで1サービスごとに管理してる。

でも最近SSOの流れに、ホントにこれでいいのか疑問に思ってきた。

セキュリティ的にはSSOの方が安全なのかなぁ。

だってSSO提供側のTwitterGoogleに比べれば大抵のサービス認証突破やすいし。

あと利便性SSOの方が上だよなあ。

シングルサインオンの名のとおり、SSO提供サービスログインしてればそのままそのサービスログインできるんだし。


でも自分Twitterアカウントを他のサービスに知られるとか嫌なんだよなあ。

連携させたい一部サービスを除いて、なんか気持ち悪くて…。

あと複数サービスSSO対応してる時どれで認証すれば良いのか分からなくなっちゃうし。

みんなどうしてんのかなあ。


関係ないけど、はてなSSO対応してるんだね。

でもGoogle+のSSOだけって。ウケる

2017-04-21

Orarioとスクレイピング大学側の対応について

すでに学生でもないのになぜこの件について書いているか自分でも分からないが、例の穏便でない大学教授発言ブーストされた感がある。

まず前提として、ID/パスワードを用いてスクレイピングを行うサービスのものは、特殊というほどではない。そのようなサービスはすでにいくつも存在するし、最も有名なところでは口座アグリゲーションサービスMoneyForward等)だ。彼らは業としてそのようなサービスをおこなっている。セキュリティのこと少しでもわかる人間ならそんなサービスやらない、というほどでもない。ただし、セキュリティが分かる人間であればあるほど慎重になる、というのは確かではある。通常ID/パスワードを渡すということは、全権委任とおなじだ。また、ログイン後の行動について、自分がやったか第三者がやったか、全く判別できない状況になる。さらに通常のWebセッションと同等だとすると、パスワードリセットから完全なアカウント乗っ取りまであり得る。つまりサービス事業者に対してよほど強い信頼関係がなければ厳しい、ということになる。

クラウド上で動いているかスマホ上で動いているか、という話は、それほどは重要ではない。クラウドしろスマホアプリしろ、すべてサービス事業者側の組んだプログラム意図に従って動くものであることは確かだからだ。

ただしクラウド上ではユーザが想定していない動作を行っているのかどうかという検証しにくいという問題があるとはいえる。とはいユーザが予め意図した行動から外れることをしてないのであれば、クラウドからアクセスでも別にそれは問題ないわけで、その点で、Orario側の主張であるスマホで動かしているのだから」という主張は、ちょっと見当はずれではある。

なお、ユーザインタラクションを介さな自動的アクセス自体サービス要件に含まれ場合スマホでは厳しいためクラウドアクセス主体が置かれる、というのは、まああり得る。口座アグリゲーションはその典型的ものだろう。Orarioの場合は、たぶんその必要はないのだと思う。

正規手段として学認があるのになぜしない?という主張は、マジでひどいと思う。普通に考えて、ぼっと出の1ベンチャートラストサークルに加えてもらえると思っているのか。このような主張は、Google/Facebookレベル自由APIクライアント登録ができるようになっていて、初めて言えるものだろう。通常は、世に受け入れられるサービスが出て初めて実行力を認めてもらえる、にわとりたまごの話ではないのか。そもそも、学認のShibboleth仕様で、そのような履修情報のやりとりがそもそもできるようになっているのか疑わしい。ホントSSOできるだけではないのか?

大学側にお伺いを立てるべき、という筋論は、そりゃそうかもしれないけど、やっぱりにわとりたまごだと思う。ビジネスの筋論っていうやつは、内輪だけの論理になっている場合が多いし、正直ステークホルダー既得権益側だったりするわけで、話が通じるとは思えない。そのようなもの破壊していくのは常に外部からだろうし、それを単なる破壊行為ではなくDisruptionにできるのは唯一ユーザからの支持であるわけだけど、Orarioは最低限そこはできていたようにもみえる。例の教授はどうも内側のメンバーの感じがひしひしと出ており、傍目から見ると、そりゃそのポジションじゃあね感が強い。

事業モデルがわからいから怪しい、事業が成り立つとしたら収集したデータ第三者への販売ぐらいしかないはずだ、という主張は、気持ちはわかるもの論理として弱い。怪しいサービスに預けるな、というのは、意見の表明ではあるかもしれないが、普遍的に怪しさを証明するには根拠が足りていない。利用規約レベルではまだなんとでもいえる。逆に言うと、Orario側は、そういう色が少しでもあったのでは?と思わせるような内容を否定してさえいけば、その点では勝てるが、やっぱりそこは何らかの形で検討して行きたかったのでは、とも思えるので、そういう将来の自分たち制限することはことはあまりやりたくないだろうなとは思う。

結論を言うと、とりあえず大学側はもうすこしトーンを落としてほしい。このままではFUDだといわれても仕方ない。単位云々の脅しは傲慢以外の何物でもない。少なくとも卒業生にとってそのような大学いたことを恥じるレベルである。嫌なのは分かるが、銀行とかだってそうだったはずだ。もうすこし長い目で見てあげられないのか。ID/パスワードを預けることのユーザへの注意喚起は、もちろん正当だが、それを認識して預けていることについてとやかく言うことは得策でない。

そして、Orario側は、自分たちがやっているサービス説明に少し時間を割いてもいいと思う。特に何をどのように取得しているのか、明確にすることは重要だ。大半のユーザたちはそういうこと気にしないとしても、自分たち自身自分たちサービス定義するのに役に立つし、今はEvilでなかったとしてもいつかEvilになってしまうのを防ぐという意味合いもある。面倒かもしれないが、取得範囲を明確にすることは信頼を得るということであり、最終的にユーザの獲得に寄与するだろう。

2016-04-26

anond:20160426145507 の続き

anond:20160426124418anond:20160426145507 の続きだゾ。てか長えよ

(略: トークンが定期的に期限切れになるので可用性が下がる。たとえばビデオカメラから複数動画アップロードしている途中で切れたらムキーってなる。再認証して途中からできるのもそれはそれで CSRF の温床。AFCP のような場合は期限切れがあってはならないので、パスワード等を預かる認証プロキシSaaS アプリを筆者は作った。好評だったが、これはもちろん本来あるべきでない欠陥のexploitのはず。)

(略: 個人ユーザ向けのAPI設計ばかりで、雇用者上司アカウント管理するという観点がない。SAMLでは普通にできるのに、OAuthとなるとセキュリティ的に云々と言って拒むサービスばかり。別のUIで既にできてることをAPIにしても意味がない。これまでできなかったことをAPIで可能にするのではなく、単なるシングルサインオンでよければ他にある。実際Googleは個人向けにはOAuth活用しているが、Google Apps for BusinessはOAuth以外のシステムを使っている。)

(略: 主要な設計ミスは、外部サービスすべてを同等に疑うところ。管理者が各サービスの信用性を判断して権限を調節できるようにしないところ。これまでどれほど多くの製品OAuthの面倒さのために失敗してきたことか。)

普通実装における」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 サービス作業できるか、そのサービスでどの操作を実行できるか、どの権限作業しなければいけないかを指定できます。この認証情報必要に応じて「アカウントホルダ」の人が破棄することもできます

AmazonAPI における認証承認技術には、本質的制限が多く潜在的危険性のあるリダイレクトを一切必要しません。Amazonプロトコル認証情報は、直接送ることは一切なく、データ署名に使うのであって、これでブラウザを通してパラメータを送る必要のあるときにも改竄不可能にすることができるのです。

Amazon設計アカウントの利用状況を API の利用まで適切に把握できますし、API認証承認もすべて Amazonからスタートし、その際のアプリ認証情報も「Amazon の」コントロールパネルから生成されます。この認証情報はその後、いかなるトークン交換システムも使わず直接 API プロセスで使われます。この設計なら「普通実装における」OAuth が達成している真のセキュリティ目標をすべて達成し、かつ前述したセキュリティ上およびユーザビリティ上の問題をすべて回避しています

ひとつ言及せざるをえない短所は、Amazon権限システムが幾分わかりにくく、あまりユーザに優しくないということです。ただし、このことは何故かほとんどのコントロールパネルにも言えることで、いずれにせよ UI 設計問題であって、承認プロセス自体の失点ではありません。さらに、Amazonコントロールパネルはかなりキビキビ使えて、それ自体API でも使えます。この点たとえば Google場合のように、筆者の知る限りメタ API もなく、何をするにも何十もの手順が必要なのとは大違いです。

Amazon認証および承認メソッドは他のサービスプロバイダにも幾つかコピーされていますGoogle 自身企業向け製品の一部でこれを利用できるようにしていますGoogle 自身純粋OAuth 設計企業サービスに向いていないことを認めており、企業サービスには JSON Web Tokens (JWT) の利用を推奨しています

JWT はサービス間の SSOAPI 利用を可能にする規格です。多くの点で JWT は SAML に似ていますが、SAML はややこしくて、XML Security (名前と違って、まったくセキュアではない) の上に構築され、API 利用に向いていないのに比べ、JWT は SAML の主要な目標を、単純かつ使いやす方法で一切の面倒なく達成しています。HMAC 実装ひとつ用意し、JSON の構築と解析の方法を知っておけば JWT は使えます既製品をお求めでしたら、膨大な JWT ライブラリが既に存在していますよ。

ただ Google場合典型的な JWT 利用法よりも高度で、HMAC のかわりに、もっと高度ですがこの分野では人気の低い RSA デジタル署名を利用するよう要求していますGoogleコントロールパネルではアカウント管理者自分企業サービス用に新しい鍵ペアを生成でき、API ログイン署名するために使う秘密鍵ダウンロードできます。こちらのほうが HMAC よりセキュリティは高いですが、Googleプロセス全体を本当に無駄に複雑化していますコントロールパネルしょっちゅう完全に再設計して、前と同じことをしたいのに使い方が違っていて混乱する点は言うまでもありません。JWT 利用の実例必要なら他をあたるようお勧めします。

他に使われている技術は、サードパーティがどんな権限必要としているかをある種の XMLJSON ファイル定義してウェブサイト送信できるようにするサービスのものです。ユーザがあるページを自分アカウント訪問し、ファイル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

http://no-oauth.insanecoding.org/

 
ログイン ユーザー登録
ようこそ ゲスト さん