問題タブ [thinktecture-ident-model]

Microsoft のクレームベース認証の実装は、真のクレームベースのセットアップの期待に応えられていないことがわかりました。ThinkTectureは、Web API 実装をうまく置き換えているようです。

AccountController の VS2013 の既定の SPA テンプレートから ThinkTecture アプローチに移行するためのガイドまたはブログ投稿があるかどうか疑問に思っています。

AspNetUsers と Roles のテーブルを作成するデフォルトの Microsoft Web API AccountController も気に入っていますが、ThinkTecture が同じことを行うかどうかはわかりません。

ThinkTectureが持っているすべてのリポジトリの間で少し混乱していると思います。IdentityServer、 、IdentityModel.45、またはを何を使用するかに関して、確固たるガイダンスを持っている人はいますAuthorizationServerか?

Microsoft のアプローチ全体を破棄して、適切な真のクレームベースのアプローチを使用することを検討していますがEF6 migrations、ID テーブル、使用するプロジェクト、または AccountController アプローチ全体を破棄する方法に関して、ちょっと助けが必要ですVS2013 の SPA テンプレート。Dominick のブログを見たことがありますが、とても良さそうに見えますが、Web API アプローチから ThinkTecture の考え方に移行するのに役立つ投稿は見つかりませんでした。

WIF とThinktecture.IdentityModel. ただし、許可されていない要求を傍受するだけでなく、現在のユーザーがアクセスできるリンクのみを表示するようにナビゲーション メニューをトリミングしたいと考えています。

私の最初の考えは、アクションのリスト (ActionResult、ActionLink、ルート値辞書、まだよくわかりません) を受け入れて、カスタムClaimsAuthorizationManger.CheckAccessルーチンを実行することです。これを行うには、AuthorizationContext を生成する必要がありますが、コンテキストを作成するフレームワーク ユーティリティ (またはできれば抽象化) にアクセスできるかどうかはわかりません。これが可能かどうか誰でも知っていますか？または、私がこれについてすべて間違っているとしたら、あなたは何を提案しますか?

ありがとう、そして楽しい休日を！

消費者に発行されたトークンを無効化または削除する方法を探しています。

シナリオは、ユーザーのパスワードが変更されたときに、発行されたすべてのトークンを使用できないようにすることです。

Thinktecture IdentityServer と WCF サービスを使用して SAML2 STS をセットアップしています。アイデアは、Thinktecture にアサーションを提供させ、それを WCF サービスで使用することです。

これで、SAML 11 アサーション - urn:oasis:names:tc:SAML:1.0:assertion で問題なく実行できました。

アサーションは次のようなものです。

現在、要件は、以前のバージョンではなく、SAML2 を使用することです。したがって、Thinktecture でトークン タイプを変更するのは簡単で、新しいアサーションは問題なく生成され、クライアントによって問題なく選択されます。

新しい SAML2 アサーション:

しかし、新しいアサーションを渡して WCF を使用しようとすると、例外が発生します。

• XmlException: BinarySecretSecurityToken の 'urn:oasis:names:tc:SAML:2.0:assertion' 名前空間で、'' ValueType を持つ 'Assertion' 要素からトークンを読み取れません。この要素が有効であると予想される場合は、指定された名前、名前空間、および値の型を持つトークンを消費するようにセキュリティが構成されていることを確認してください

WCF web.config の抜粋を次に示します。

では、何が間違っているのでしょうか?

まず第一に、私はすべての同様の投稿を経験しましたが、私の問題を解決するものは何もありません. また、少なくとも Fiddler と Chrome 開発ツールに示されているように、適切な応答ヘッダーを受け取っているため、サーバー側に問題がないことも除外しました。

私はThinktecture.IdentityModelを使用しており、次のように jquery を使用してクライアント側で認証を行いました。

これが私が得たトレースです：

* プリフライト CORS リクエスト *

プリフライト応答

実際の AJAX リクエスト

AJAX レスポンス

サーバー呼び出しが成功したことを示す [Fiddler] タブの TextView からのトレースの最後の行に注意してください。サーバー側のコードをデバッグし、その出力を返すコードに到達し、エラーをスローしなかったため、サーバー呼び出しが成功したことを確認できます。それを機能させる方法はありますか？

(この問題をこことgithubの両方に投稿して申し訳ありませんが、これについて本当に助けが必要です..)

Thinktecture.IdentityModel.45 で認証を使用している場合、CORS (System.Web.Http.Cors) を有効にできません。

トークンのエンドポイントに問題があり、デフォルトの "/token" を使用しています。

/token を (javascript クライアントから) 呼び出すと、ブラウザーは "/token" リソースに対する "OPTION" 呼び出しと "GET" 呼び出しの 2 つの呼び出しを発行します。リクエストが正しいCORSポリシーを取得し、それが返されることを確認できるようにするためだけに、単純なPolicyProviderFactoryを使用しています

最初の OPTION 呼び出しが機能し、GetCorsPolicyProvider がヒットします。他の呼び出しは機能しますが、GetCorsPolicyProvider はヒットせず、その結果、サーバーはすべての正しいヘッダーなどを含む 200 OK を返しますが、コンテンツの応答は空です。

ルート構成のトークン リソースに次を追加する必要がありました。そうしないと、「NOT FOUND」が表示されます。

他のすべての要求では、OPTIONS と GET の両方が CORS ポリシー プロバイダーを呼び出し、すべてが機能します。thinktecture.identitymodel と正しい応答にデバッグしました。正しいトークンが返されます。

/token リソースの GET メソッドは、CORS ポリシー プロバイダーを呼び出しません..しかし、なぜですか? CorsMessageHandler はロードされますが、呼び出されません。リクエストが CORS/CorsMessageHandler をトリガーするかどうかはどうすればわかりますか?

診断トレース:

認証構成は次のようになります。

現在、MVC 4 アプリケーションで CORS サポートに Thinktecture パッケージを使用しています。メソッドに出力キャッシュ属性を追加すると、HTTP ヘッダーがおそらくキャッシュされ、ORIGIN がリクエストに対して変更されないため、CORS サポートが失われます。メモリ キャッシュを使用できることはわかっていますが、面倒です。

brockallen のブログで説明されているように、セッション認証モジュール (SAM) と Thinktecture IdentityModel を使用して WIF でスライディング セッションを使用する場合。発行されて Cookie に書き込まれたセッション セキュリティ トークンは、必要に応じて「有効」に拡張され、それに応じて Cookie が設定されます。

ただし、現在のクレーム ID にシリアル化された BootStrapToken は古いもののままであり、トークンが期限切れになる可能性があります。これにより、さまざまな理由でブートストラップ コンテキスト トークンを使用しようとすると問題が発生します (その中には、「貧乏人」の委任の実装が含まれる可能性があります)。

新しく発行されたトークンでブートストラップ トークンを更新する最良の方法は何ですか?