問題タブ [authorization]

REST APIまたはサービスを設計するとき、セキュリティ（認証、承認、ID管理）を処理するための確立されたベストプラクティスはありますか？

SOAP APIを構築するときは、ガイドとしてWS-Securityがあり、このトピックに関する多くの文献があります。RESTエンドポイントの保護に関する情報が少なくなっています。

RESTには意図的にWS-*に類似した仕様がないことは理解していますが、ベストプラクティスまたは推奨されるパターンが出現したことを期待しています。

議論や関連文書へのリンクをいただければ幸いです。重要な場合は、.NETFrameworkのv3.5を使用して構築されたRESTAPI/サービスのPOX/JSONシリアル化メッセージでWCFを使用します。

Enterprise LibraryのAzMan認証プロバイダーを使用してWinFormsアプリケーションから認証チェックを実行していますが、次のエラーが発生します。

パスワードを更新できません。現在のパスワードとして提供された値が正しくありません。（HRESULTからの例外：0x8007052B）（Microsoft.Practices.EnterpriseLibrary.Security.AzMan）

---

パスワードを更新できません。現在のパスワードとして提供された値が正しくありません。（HRESULTからの例外：0x8007052B）（Microsoft.Interop.Security.AzRoles）

AzManストアは、同じドメイン内の別のコンピューター上のADAMでホストされています。他のコンピューターやユーザーにはこの問題はありません。電話をかけるユーザーは、ADAMストアとAzManストアの両方への読み取りアクセス権を持っています。WinFormsアプリを実行しているコンピューターとADAMを実行しているコンピューターは、どちらもWindowsXPSP2上にあります。

解決する前にAzManでアクセスの問題が発生しましたが、これは新しいものです...何が欠けていますか？

asp.netWebサイトの1つのページに対してすべてのユーザーを承認するための最良の方法は何ですか。

ログインページと他の1つのページを除いて、私はすべてのユーザーがWebサイトのページを表示することを拒否します。

このページにすべてのユーザーがアクセスできるようにするにはどうすればよいですか？

データベースにアクセスできる従業員がアカウントにアクセスできるようにすることなく、システムでユーザーアカウント管理を処理する最良の方法は何ですか?

例:

1. ユーザー名/パスワードをデータベースに保存します。データベースにアクセスできる人なら誰でもユーザー名とパスワードを見ることができるため、これは悪い考えです。したがって、それを使用します。

2. ユーザー名/パスワードのハッシュを保存します。これはより良い方法ですが、データベース内のパスワード ハッシュを、認証情報を知っている別のアカウントのハッシュに置き換えることで、アカウントにアクセスできます。次に、アクセスが許可された後、データベースに戻します。

Windows/* nix はこれをどのように処理しますか?

次の目的でシステムをどのように実装しますか。

• 現在、サードパーティ ベンダーのアプリケーションと緊密に統合されている何十万もの既存ユーザーの認証と承認を管理し ます (これらのユーザーを、私たちが管理するものに追い出し、アプリをそれに対抗させ、さらにサード パーティ ベンダーに対抗させたいと考えています)。
• それらのユーザーにリンクされたプロファイル情報を管理します
• ほぼすべてのプラットフォーム (Windows、*nix、PHP、ASP/C#、Python/Django など) 上の任意の数の Web アプリケーションからアクセスできる必要があります。

ここにいくつかのサンプル実装があります:

• すべてを管理する LDAP/AD サーバー。すべてのプロファイル データにカスタム スキーマを使用します。すべてが LDAP/AD に対して認証でき、あらゆる種類の ACL とプロファイル データをカスタム スキーマに保存できます。
• 認証のみに LDAP/AD を使用し、従来のデータベース (MSSQL/PostgreSQL/MySQL) またはドキュメント ベースの DB (CouchDB、SimpleDB など) を使用して、LDAP ユーザーを最も堅牢なプロファイル/承認サーバーに結び付けます。認証には LDAP を使用し、より高度な機能については DB にアクセスします。
• すべてに従来のデータベース (リレーショナルまたはドキュメント) を使用します。

この3つのうち、どれがベストですか？上記の目的に適合し、実装がより簡単な他のソリューションはありますか?

** ユーザー データベースに対して認証を行うほぼすべてのアプリケーションが、私たちの管理下にあることを付け加えておきます。唯一の部外者は、現在のユーザー データベースを削除するアプリケーションと、おそらく 1 つまたは 2 つの他のアプリケーションです。openID サーバーを必要とするほど広いものはありません。

これらのユーザーの多くがこれらのアカウントを 5 ～ 8 年間使用しており、ログインやパスワードなどを知っていることも重要です。

SVN を使用してリポジトリをセットアップし、プロジェクトをアップロードしました。これらのプロジェクトには複数のユーザーが取り組んでいます。ただし、誰もがすべてのプロジェクトへのアクセスを必要とするわけではありません。プロジェクトごとにユーザー権限を設定したい。

どうすればこれを達成できますか？

安全なWCFサービスを実装しています。認証は、ユーザー名/パスワードまたはWindowsクレデンシャルを使用して行われます。このサービスは、Windowsサービスプロセスでホストされます。今、私は各サービス操作の承認を実装するための最良の方法を見つけようとしています。

たとえば、次の方法について考えてみます。

ご存知かもしれませんが、WCFには、呼び出し元/クライアントから渡されたセキュリティ資格情報を取得できるOperationContextオブジェクトがあります。これで、メソッドの最初の行が呼び出されるまでに、認証はすでに終了しているはずです。しかし、決定が入力データ自体に依存する場合、どのように承認を実装しますか？たとえば、上記の場合、「admin」ユーザー（権限などがデータベースに保存されている）はエンティティ情報の取得を許可され、他のユーザーは許可されるべきではありません...承認チェックはどこに配置しますか？

次のように、メソッドの最初の行に配置するとします。

ここで、いくつかの質問があります。

1. 承認チェックの前または承認チェックの内部でentityIdを検証しますか（たとえば、null /空の値をチェックしますか？）言い換えれば、承認チェックをすべてのメソッドに含める必要がある場合、それは良いパターンですか？どちらを最初に行う必要がありますか-引数の検証または承認？

2. 承認チェックがこのように至る所にあり、単体テストにOperationContextがない場合、WCFサービスを単体テストするにはどうすればよいですか？（WCFを設定せずに、このサービスクラスの実装を直接テストしようとしていると仮定します）。

アイデアはありますか？

XML-RPC仕様に正確に準拠しているわけではありませんが、概念はほぼ同じです。クライアントは、XMLペイロードを使用してHTTP/HTTPS経由で着信します。リクエストに応答するXMLペイロードで応答します。これは主にマシン間で行われるため、ユーザー名/パスワードを入力する人は誰もいません。私たちのコンストラクトはapachetomcat内で実行されます。リクエストを認証したいと思います。すべてのクライアントがすべてのサービスを利用できるわけではないため、リクエストも承認する必要があります。サブスクリプションと使用ごとの課金モデルの両方があるため、すべてをログに記録する必要があります。

サーバーとクライアントの両方に何をお勧めしますか？

JDBC レルムは、属性 userNameCol および userCredCol によって定義された列を含む認証用のテーブル構造を指定します。これらは、FORM または BASIC auth-methods にとって意味のあるユーザーとパスワードに対応します。それらは対話型であり、クライアントのユーザーからこれら 2 つの部分を必要とします。

• 証明書から何が返ってきますか?
• userNameCol と userCredCol に格納されているデータの例はどのようなものでしょうか?
• この場合、レルムの代替テーブル構造はありますか?

PS - Tomcat 5.5.x を使用しています。

アプリケーションの公開や共同作業には、多くの場合、リソースへのアクセスの共有が含まれます。ポータルでは、ユーザーは、グループのメンバーとして、または明示的なアクセスのために、特定のコンテンツへのアクセスを許可される場合があります。コンテンツの完全なセットには、パブリック コンテンツ、グループ メンバーシップ コンテンツ、およびプライベート ユーザー コンテンツを含めることができます。または、共同アプリケーションを使用して、ワークフローの一部としてリソースを渡したり、編集目的でドキュメントの管理を共有したりしたい場合があります。

ほとんどのアプリケーションはこれらのリソースをデータベースに保存するため、通常は「編集できるすべてのドキュメントを取得する」または「表示できるすべてのコンテンツを取得する」などのクエリを作成します。「編集可能」と「閲覧可能」はユーザーの権限です。

2 つの質問があります。

1. リソースを取得したら、ユーザーを承認するのは非常に簡単ですが、使用可能なリソースのリストに対して効率的に承認を行うにはどうすればよいでしょうか? と、

2. この種の承認は、アプリケーションのコアから分離できますか? おそらく別のサービスに？分離したら、「Get me all the documents I can see with title like [SomeSearchTerm]」のようなクエリをどのようにフィルタリングできますか? あなたの別のシステムは、多くの参照データをコピーする必要があるようです。