問題タブ [thinktecture-ident-model]

通常のフォーム認証に加えて、Thinktecture IdentityModel で設定された Web Api DAL によって提供される API/トークン URL に対して WebClient オブジェクトが基本認証を行うように、フォーム認証ログイン プロセスを変更することは難しくありません。返されたセッション トークンは、後で DAL を呼び出すときに使用するために、セッション ディクショナリに格納できます。

問題は、これらのトークンの寿命が異なることです。

必要に応じてセッション トークンを再作成するために、資格情報を localStorage に保持するようにアプリを書き直すこともできますが、それは見苦しく、セキュリティの観点からは理想的ではありません。

これらのシステムのいずれかまたは両方でトークンの耐久性を構成する方法がある可能性がありますが、使用する検索用語がわかりません (トークンの耐久性とトークンの寿命を検索してみましたが、結果は役に立ちませんでした)。

私は、2 種類の Web アプリケーション セキュリティを最適に調整する方法について、哲学的および実用的な提案に興味があります。何を検索すればよいかを知っていれば、このトピックに関する回答がまだなかったとしたら、非常に驚​​くでしょう。

一部の人々は私が何を求めているのかはっきりしていないので、少し背景を説明します。

フォームベースのセキュリティを使用する、醜い古い学校の ASP.NET Web アプリがあります。

Thinktecture IdentityModel を使用する別の DAL アプリとして新しいものを追加しました。この DAL は、ASP.NET アプリと Durandal SPA の 2 つのアプリで使用されます。

これらは資格証明チェックに同じデータベースを使用するため、同じ ID スペースを持ちます。

古いアプリのログイン プロセスを変更して、資格情報を提示し、Thinktecture IdentityModel からセッション トークンを取得できるようにしました。このトークンは、古いアプリが DAL を呼び出すたびに提示される Session コレクションに入れられます。

古いアプリを起動し、認証し、操作を行ってブラウザーを閉じ、後でブラウザーを再度開くと、ログインせずに ASP.NET アプリにログインしているため、セッション トークンを作成する機会がありません。これが問題です。同じライフサイクルを持つには、2 つのトークンが必要です。

1つの可能なアプローチを考えました。人々がそのメリットについて意見を表明したり、洗練された提案のコメントをしたりできるように、私はそれを答えとして以下に提示しています. 他のアイデアを思いついたら、答えとして投げます。あなたも同じことをしてくれることを願っています.

Thinktecture Authorization Server からアクセス トークンを取得できません。許可コードを正常に取得した後、トークン エンドポイントに POST 要求を送信しようとしましたが、常に次の応答で 400 Bad Request が返されます: message: "{ "error": "invalid_client" }"

私のリクエストは: https://host/authz/users/oauth/tokenへの POST リクエスト本文: {"code":"grant_code_received_from_previous_request","client_id":"myclient","grant_type":"authorization_code","client_secret" ："私の秘密"}

私のクライアントは認証サーバーで適切にセットアップされています。クライアント ID とシークレットは正しいです。これらは、前のリクエスト (/users/oauth/authorize) で許可コードに使用した値と同じです。

この「invalid_client」の問題について何か考えはありますか? 応答には「invalid_client」以外の情報はありません。

私が書いたカスタム Authorization 属性が本当に良いアイデアかどうかを判断しようとしています。

シナリオ
店舗のコレクションがあり、それぞれStoreに所有者がいるとします。ストアで CRUD 操作を実行できるのは、ストアの所有者だけです。Claim基本的に所有権の要件をオーバーライドし、任意のストアで CRUD 操作を実行できると言うユーザーを除きます。

補足: Thinktecture と ADFS を使用しています

そのため、ユーザーが所有者ではなく、承認チェックを通過できる「オーバーライド」する適切な主張を持っているかどうかを確認するために使用されるStoreOwnerAuthorizeパラメーターの属性を作成しました。("Manage", "Stores")

「ManageStores」のようなクレームを持ち、属性内でデータベース呼び出しを行うことについてどう思うかわかりません。必要なことを正確に達成しているにもかかわらず、間違った道を進んでいると思わせてくれます。

API ルート

API メソッド

StoreOwnerAuthorizeAttribute

Identity サーバー v3 の CustomUserService サンプルを使用しています。以下のようにホームコントローラーを追加しました - `public class HomeController : Controller { // // GET: /Home/ public ActionResult Index() { return View(); }

また、About.cshtml と Index.cshtml の 2 つのビューを追加しました。ご覧のとおり、About アクションには Authorize 属性があります。そのため、[About] に移動すると、Identity Server V3 のログイン ページにリダイレクトされるはずですが、そうはなりません。私の完全なstartup.csは次のとおりです-

WSfederation を使用したいので、CustomerUserService サンプルを使用しています。そのため、ADFS は ID サーバーにクレームを提供し、次に ID サーバーはそれらのクレームを About ビューに返す必要があります。誰でもここで私を助けることができますか？