問題タブ [thinktecture-ident-model]

ASP.NET WebAPI を使用して認証する ASP.NET MVC Web サイトがあります。基本認証とセッション トークンに ThinkTecture IdentityModel を使用しています。これはローカルでも Azure Web サイトでも問題なく動作します。ただし、Azure クラウド サービスに移行する必要があり、現在はトークンで認証できず、常に 401 エラーを受け取りますが、ユーザー名とパスワードだけで問題なく動作します。

私が推測できる唯一の違いは、IIS に対処しなければならないことです。トークンによる認証を許可するために必要な変更はありますか?

更新しました：

認証に Web.Config 構成を使用していません。WebAPIConfig で次のコードを使用しているだけです。

プロジェクトで ThinkTecture.IdentityModel の使用を開始しましたが、深刻な問題に直面しています。同じことで私を助けてください。

エラー 1 「タイプ 'System.IdentityModel.Tokens.SecurityToken' は、参照されていないアセンブリで定義されています。アセンブリ 'System.IdentityModel, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089' への参照を追加する必要があります」

Web サイト (MVC4/シングル ページ アプリケーション + ノックアウト + Web.API) を実装する必要があり、大量の記事やフォーラムを読んできましたが、セキュリティ/認証のいくつかのポイントとその方法についてまだ理解できません。ログインページと Web.API を保護するときに先に進みます。

サイトは完全に SSL で動作します。ユーザーが初めてログオンすると、登録プロセスを確認するためのリンクが記載された電子メールが送信されます。パスワードと「salt」値は暗号化されてデータベースに保存され、パスワードが解読される可能性はありません。この API は、このアプリケーション専用に使用されます。

さらに先に進む前に、いくつかの質問に答える必要があります。

1. セキュリティの観点から、どの方法が私のアプリケーションに最適でしょうか: Basic/SimpleMembership? 他の可能性はありますか？
2. オブジェクト Principal/IPrincipal は基本認証だけで使用されますか?
3. 私の知る限り、SimpleMembership を使用すると、Cookie が使用されるため、これは RESTful パラダイムを壊していませんか? では、REST Web.API を構築する場合、SimpleMembership の使用を避けるべきではないでしょうか?
4. トークンを使用して、ThinkTecture.IdentityModel をチェックしていました。これは Basic、Forms、Auth などの認証タイプですか、それとも他の認証タイプに追加できるものですか?

ありがとうございました。

.Net 4.5 に asp.net MVC 4 プロジェクトがあります。

サイトを保護するためにクレーム ベース認証を設定しました。

ログイン後に非常に奇妙な動作が発生します。FedAuth Cookie を編集し、トークン部分の値を手動で変更すると、ページを更新しようとすると機能します。

私のweb.configには次のものがあります：

このフィルターをプロジェクトに登録しています

私はそのようなトークンを作成します

トークンをbase64でデコードすると、これがあります

そして、そのようにクッキー要素の最初の文字を変更します (v -> 1)

これを base64 で再エンコードし、FedAuth Cookie を挿入しましたが、引き続き機能します

これを解決するためにどこから始めるべきかについて何か考えはありますか?

ありがとう

昨日、プロジェクトを IdentityModel 2.6 で更新しましたが、このエラーでコンパイルされない理由がわかりません。

パッケージを更新したばかりで、コードの変更はありません。

編集: 問題は、ここで説明されている web.config セクションの欠落から発生しますhttp://brockallen.com/2013/05/28/configuration-for-wif-session-helper-apis-in-thinktecture-identitymodel/

これは必須のようで、すべての属性を入力する必要があります。

これについてより多くの情報が得られることは素晴らしいことです。

ティア

WIF と、ThinkTecture STS を使用したフェデレーション セキュリティ モデルを使用しています。

http://domain.com/#pageという URL を要求しようとすると、認証後に WIF が正しいページにリダイレクトされません。

wctxのruパラメータに/#pathの正しいパスが含まれていません。代わりに、ハッシュとそれ以降のすべてを無視するため、ruパラメータは/になります。ハッシュのない通常の URL は正常に機能します。

これにはワークアウトがありますか、それとも URL のフォーマットが間違っていますか?
助言がありますか？

OAuth 2 リソース オーナー フローを使用して、Web API サービスに対してモバイル クライアントを承認しようとしています。Thinktecture IdentityServer を使用して、対称署名鍵で jwt トークンを発行しています。

クライアント側では、Thinktecture IdentityModel を使用してトークンの検証をセットアップしています。私の WebApiConfig は次のようになります。

私の IdentityModel.config には、次のものがあります。

主にhttp://leastprivilege.com/2013/07/16/identityserver-using-ws-federation-with-jwt-tokens-and-symmetric-signatures/のこのリンクから取得 しました。これは、このスタック オーバーフローの投稿で見つけました。対称キーで Microsoft JWT を構成するには?

その投稿にある派生クラスを使用しようとしましたが、この行を実行しようとしたとき:

IssuerTokenResolver のタイプが X509CertificateStoreResolver であり、NamedKeyIssuerTokenResolver のタイプではないため、InvalidCastException が発生します。

正しい TokenResolver を構成するために、構成またはコードにまだ何かが欠けているようです。誰か考えがありますか？