c# - ソフトウェア開発者が承認を外部化しない理由はありますか？

Question

IDの外部化の価値提案は、多くのサイトがOpenID、CardSpace、またはフェデレーションIDを受け入れるようになり始めています。ただし、多くの開発者は、承認を外部化し、XACMLに基づくアプローチを使用するための次のステップをまだ実行していません。

理由は意識の欠如か何か他のものですか？ソフトウェア開発へのXACMLベースのアプローチについてどのように学ぶと思いますか？

私は認証ではなく承認について質問していることに注意してください。

score 15 · Accepted Answer

承認の外部化の見通しは、認証（OpenID、CardSpaceなど）の外部化よりもはるかに難しいと思います。これは主に、承認がアプリケーション固有のものであるという事実によるものです。人物Aが私のアプリケーションで実行することを許可されている場合、彼はあなたのアプリケーションで実行できない可能性があります。それは、私のアプリケーションとあなたのアプリケーションの間に共通の平行関係があると仮定しても、おそらく存在しないでしょう。

外部化の承認が決して行われないとは言いたくありませんが、正直なところ、あなたが本当にそうしたいと思う理由を思いつくのに苦労しています。並行して動作する一連のアプリケーションの場合もありますが、これも外部ではなく内部でサポートされる可能性があります。

score 5 · Accepted Answer

また、承認 !== 認証であることを覚えておいてください。ユーザーが認証されたからといって、サイトの認証部分を解決したわけではありません。誰がいつ何をするかを決定する必要があります。

score 3 · Accepted Answer

私たちが独自のものを展開し続ける主な理由は、openid などのオプションが技術サイトでのみサポートされているように見えるためです。私たちは小規模なプレーヤーであるため、ユーザーの受け入れが大きくなるまで、外部プロバイダーの使用を開始しません。

ユーザーが私たちのサイトで最初にしなければならないことが、別のサイトへの移動を伴うことを望んでいません。

score 2 · Accepted Answer

私は他の人が持っている誤解に陥ったようです-質問は外部承認についてでした。個人的には、認証サーバーと承認サーバーを制御できるローカルネットワークでの分散承認のみを信頼します。Webサイトで外部認証を使用することは決してありません。

以下は、認証サービスとしてのOpenIDについての私のコメントです。

1）指摘されたように、承認！=認証。OpenIDは認証を処理しますが、Webアプリの所有者は、そのログインに割り当てられた権限を完全に制御できます。これはポジティブですが、これについての混乱はネガティブです。

2）リンクが見つかりませんが、OpenIDはソーシャルエンジニアリング/中間者/フィッシング攻撃に対してオープンです。プロバイダーはこれを防止しようとしますが（IDイメージ、ブラウザー証明書、コールバック検証など）、ブラックハットサイトが「OpenIDユーザー名とパスワードを入力してください」というダイアログ/ページと天才をポップアップする場合は役に立ちませんユーザーが準拠します。

3）フェデレーションIDの各プロバイダーには、IDを使用するサイトに関係なく、ユーザーのすべてのアクティビティを追跡する機能があります（責任があると言う人もいます）。これが、グーグルとヤフーがフェデレーションIDを提供するためのガンホーである理由ですが、それらを消費することにそれほど興奮していません。

4）上記のコメントとは逆に、OpenIDを使用すると、登録の障壁が減るのが一般的です。特に、便利なUIが、新しいユーザーがすでにOpenIDを持っている可能性があることを示している場合はそうです。これは、RPXなどのOpenID/OAuthソリューションを組み合わせて使用する場合にさらに当てはまります。

したがって、私の観点からは、OpenIDを使用するリスクは、Webサイトではなく、ユーザーにあります。さらに別のユーザーIDとパスワードを覚えさせて、ユーザーがフィッシングされるのを防ぐことはできません。さらに、Black Hatsは、ユーザーの他のアカウントにアクセスするために、サイトのユーザーパスワードをプレーンテキストで保存するよりも悪質なことをする必要はありません。ログインするWebサイトごとに異なるパスワードを使用する人は何人いますか？

score 2 · Accepted Answer

私が行ったほとんどのプロジェクトは、大企業内で使用するための独自のアプリケーションであり、そのような場合、外部認証サービスがオプションになることはめったにありませんが、認証は代わりに何らかの内部サービス (Active Directory など) によって処理されます。

たまたま公開 Web サイトを構築するプロジェクトの一部になった場合、自分の認証をホストする代わりに、OpenID のようなものを利用しようとすることは間違いありません。

score 1 · Accepted Answer

1つの問題は、ここで発明されていないことと、（偽名でさえ）アイデンティティに対する外部化された当局の不信の組み合わせです。良い記事はここにあります：

IDプロバイダーを信頼しますか？

また、慣性かもしれないと思います。それを動かすキラーアプリがなければ、人々は移行が遅い。私が最近見たFacebook統合の数の増加を考えると、私たちは急な斜面の頂上にいて、その世界に参入しようとしていると思います。

score 1 · Accepted Answer

別のポスターが示しているように、承認は一般的にアプリケーション固有です。あるアプリケーションで実行できることは、別のアプリケーションで実行できることとは大きく異なります。特に顧客の既製のアプリケーションでは、承認は通常、アプリケーションによってより自然に処理されます。

パフォーマンスは別の懸念事項です。これは、SunのXACML実装を取得し、それを使用していくつかの承認を外部化することで確認できます。要求の両側でネットワークコストが発生します。これは、（要求/応答の設計方法などに応じて）承認決定の実際のコストをはるかに超える可能性があります。これをCOTSアプリケーションに組み込みます。このアプリケーションでは、パフォーマンスを最適化する自由が少なくなり、事態はさらに悪化します。

ただし、有望な分野のいくつかは、規制順守に関するものだと思います。アプリケーションによって変わらない承認がいくつかあります。たとえば、専有情報または機密情報または資料の転送。このような場合、逆のことが非常に悪いため、各アプリケーションに存在する同じコントロールに対して強力なケースを作成できます。同じアクセス制御に対して実装とルールをいくつでも持つことは、管理上の悪夢です。XACMLのような制御フレームワークを開始する簡単な場所は、誰かが見ることができるものから始めて、次に誰かができることを理解することかもしれません。

score 0 · Accepted Answer

いくつかの理由：

一部のコメントが示したように、「承認はローカルである」という一般的な認識があります。これは、重要なアクセス決定に必要な高品質の維持に費用がかかる「サブジェクト属性」の再利用の可能性がほとんどないことを意味します。 . (一部の法律/規制は広く適用されるため、再利用の可能性は高いと思いますが、これについての完全な議論はこの形式では長すぎます。)
データインフラストラクチャの欠如: 組織間でポリシーベースのアクセス制御を適用するには (自分のデータへのアクセスをロック解除するために他の組織の承認 (「AuthZ」) データを使用/信頼している)、少なくとも、属性のセマンティクスを理解している必要があります。（「法執行官」とは？「米国市民」とは？）あとは、わかりやすい属性の品質基準と、それに対する第三者認証があるといいですね。(これらの要件は、PKI の相互運用性の要件に類似していると考える人もいるかもしれません。それはどのように実現するのでしょうか? そして、それは 1 つのデータに加えて、それをサポートするものに対するものです。)
役割/責任への影響: 「役割」、「属性」、「デジタルポリシーを伴う属性」のいずれに対しても、承認を外部化することは、ローカルの「データ所有者」がリソースの制御を失うことを意味します。また、ユーザーリストを維持するためのかなりの作業と責任も軽減されます。この種の変更により、外部 AuthZ の実装は、技術的な問題から、政治的な側面を伴う組織的な問題にまで引き上げられます。
ほとんどの組織は、ポリシーが何であるかを知りませんし、書き留めていません。アクセスとは、「求める人」、「求めて私が好きな人」、または「データへのアクセスなど、何かを与えてくれる人」のことです。適用される実際のルールは、ポリシー言語で表現することによって強制的に公開されると、かなり醜いものになる可能性があります。また、文書化されたポリシーをデジタルポリシーに適切に表現するためのスキルセットも、ツリー上では成長しません。実際、スキルセットはビジネスアナリストまたは弁護士であり、IT 担当者ではありません。これらの人々のためのツールはほとんど存在しません。
確固たるポリシールールがある場合、それを処理するために必要な属性が存在しないことに気付く可能性があります。通常、これらの属性は、AD に既にあるようなものではありません。電話番号は AuthZ 属性として有用ではありません。また、「組織」でさえ、実際に文書化できるほとんどの法律や規制にはおそらく適切ではありません。それは、「考えられる原因」などのポリシー要件を表現するために実装する (そして承認を受ける) 必要がある回避策や概算についても言及していません。
比較的扱いやすいですが、それでも現実的なのは、非常に広く普及している COTS アプリの多くが外部認証をサポートしておらず、多くのアプリ開発者が外部化を行うことに慣れていないため、(a) 外部化をやめさせようとすることです。または（b）10セント硬貨でそれを学び、それをひどく行います。

かなり悪いですね。ですから、これにもかかわらず、ゲームはろうそくの価値があると思うと言って終わりにしましょう. 潜在的なメリットのリストは、別の投稿で別の機会に掲載します。

幸運を！

score 0 · Accepted Answer

取り組んでいるプロジェクトの種類によると思います。顧客が認証を保存したい場合、OpenID を使用する方法はありません... Google Apps エンジンを使用して小さなプロジェクトを開発しているため、Google を使用して認証を行っています。したがって、プロジェクトのタイプに大きく依存します。

score -1 · Accepted Answer

個人的には、これは外部認証について聞いた最初のことです..だから、それは単なる認識不足かもしれません.

今グーグル..

c# - ソフトウェア開発者が承認を外部化しない理由はありますか？

11 に答える 11

Related

Reference