問題タブ [thinktecture]

For questions regarding programming in ECMAScript (JavaScript/JS) and its various dialects/implementations (excluding ActionScript). Note JavaScript is NOT the same as Java! Please include all relevant tags on your question; e.g., [node.js], [jquery], [json], [reactjs], [angular], [ember.js], [vue.js], [typescript], [svelte], etc.

0 投票する
1 に答える
990 参照

authentication - 外部ユーザー管理を使用する IdentityServer3

Web でホストされている IdentityServer3 が認証のみを処理し、ユーザー認証が外部のカスタム サービスによって処理されるシナリオを考えると、これをサポートするために実装する必要があるものは何ですか? カスタム OWIN ミドルウェア?

0 投票する
1 に答える
235 参照

thinktecture - Thinktecture IdMgr + MembershipReboot を使用して、ユーザーのメール アドレスまたはパスワードを更新できません。

Thinktecture IdManager でユーザーを編集すると、名前、年齢、その他の「カスタム」プロパティを変更できますが、電子メール アドレスまたはパスワードを変更しようとすると、カスタムの Membership Reboot リポジトリ更新メソッドが 1 回呼び出されて変更が保存され、その後再び呼び出されます。変更を元に戻します。

コントローラーは、何らかの理由で AutoFac コンテナー ミドルウェアによって 2 回呼び出されます。

IdMgr アプリケーションからの HTTP ポストは 1 つしかないため、クライアント側の問題ではありません。

最初のスタック トレースは...

2 番目のスタック トレースは...

0 投票する
0 に答える
109 参照

.net-4.5 - WIF STS で SHA256 を使用してセキュリティ トークンに署名する方法は?

Thinktecture STS を使用していますが、発行されたトークンに SHA1 の代わりに SHA256 を使用して署名したいですか? 以下を使用して、アルゴリズムをアプリケーションに追加しようとしました。

しかし、それはエラーを出し始めます:

無効なアルゴリズムが指定されました

使用している証明書が SHA256 と互換性があることを知っています。何か案が?

0 投票する
1 に答える
707 参照

php - PHP での OpenID アクセス トークンの検証

PHP で thinktecture OpenId connect で SSO 検証を実行しようとしています。クライアントを作成し、アクセス トークンを取得しました。しかし、それを検証する方法がわかりません。

ドキュメントには次のように書かれています:3.2.2.9。アクセストークンの検証

認証エンドポイントから発行されたアクセス トークンを ID トークンで検証するには、クライアントは次のことを行う必要があります。

  1. ID トークンの JOSE ヘッダーの alg ヘッダー パラメーターの JWA [JWA] で指定されたハッシュ アルゴリズムを使用して、access_token の ASCII 表現のオクテットをハッシュします。たとえば、alg が RS256 の場合、使用されるハッシュ アルゴリズムは SHA-256 です。

  2. ハッシュの左半分を取得し、base64url でエンコードします。

  3. ID トークンの at_hash の値は、前のステップで生成された値と一致する必要があります。

ステップ 1 の作成方法がわかりません。ALg を RS256 として取得し、Id トークンから at_hash を取得しました。検証の方法に関する PHP の例が見つかりません。

0 投票する
2 に答える
624 参照

asp.net - VNext を使用した IdentityManager

vNext で IdentityManager を使ってみた人はいますか?

app.UseIdentityManager(IdentityManagerOptions)拡張方法に問題があります。

存在しません。

そこで、サーバー関連のすべての側面をマネージャーに変更することにより、 UseIdentityServerここにあります)用に作成された拡張メソッドを使用してみました。これを行うと、System.NullReferenceExceptionインライン 43 が得られます。

拡張メソッドを使用する方法についてのアドバイスをいただければ幸いです。

0 投票する
1 に答える
327 参照

asp.net-mvc - 暗黙的なフローに対してトークンが大きくなりすぎる - Thinktecture IdentityServer3

私は取り組んでおり、同じサーバーがリソース所有者フローに対して約 20 ~ 30 文字のアクセス トークンを返している間にIdentityServer3、私の (および ID トークン) が (最大文字数まで) 大きくなりすぎていることを確認しましAccess Tokenた。この問題はフローに固有のものですか、それとも私が何か間違ったことをしているのですか...???3000+Implicit flow

私がビジュアルスタジオソリューションに持っているのは

  • 個別/スタンドアロンの IdentityServer サーバー プロジェクト
  • Mvc アプリケーション プロジェクト (暗黙的なフローを使用)
  • コンソール アプリ (リソース所有者フローを使用)
  • Web API プロジェクト (要求ヘッダーで mvc アプリまたはコンソール アプリからアクセス トークンを取得します)

mvc アプリにログインすると、かなり大きなアクセス トークン (および ID トークン) が取得されますが、コンソール アプリの場合は、適切でコンパクトなトークンが返されます。なぜここで違いが...???

0 投票する
3 に答える
1034 参照

asp.net-mvc - asp.net mvc の本文で SAML2 (P?) トークンを認証する

現在、ユーザーが 2 つの ThinkTecture IDP サーバー経由で接続できるようにする ASP.NET MVC アプリケーションがあります。MVC アプリはこれらの IDP サーバーの両方を信頼し、ユーザーを完全に認証します。

現在の設定では、web.configのセクションで< System.IdentityModel.Services.WSFederationAuthenticationModule >と を使用してこれらを処理します。 < System.IdentityModel.Services.SessionAuthenticationModule >< modules >

SAML v2 トークンを送信してユーザーを認証したい新しい関係者がいますが、MVC アプリはそれを認識していないようです。

IDP サーバー (SAML1) と新しいログイン サーバー (SAML2) の両方からの POST 応答を比較しましたが、微妙な違いがいくつかあり、それが問題を引き起こしている可能性があります。

IDP サーバーは、< trust:RequestedSecurityToken >属性を使用してラップするよう< saml:Assertion >です。一方、新しいクライアントは、次を含む POST 要求本文を送信します。< saml >< samlp:Response >

私の質問は次のとおりです。

1)< samlp:Response >これは Microsoft WIF でサポートされていない新しい SAML2P バージョンですか? それとも< saml:Assertion >要素に興味があるだけですか?

2) WIF は SAML トークンをどこで検索しますか? ポスト本体? 認証ヘッダー (ベアラー)?

3) 現在、ユーザーが認証されていない場合、ユーザーはローカル IDP サーバーにリダイレクトされ、ログインして SAML 応答が返され、それがピックアップされます。ただし、新しいクライアントは、SAML トークンを使用してページを表示する要求を渡すだけです (真のシングル サインオン)。この違いが問題を引き起こしているのだろうか。現在、ユーザーのローカル IDP へのリダイレクトを手動で処理しているため、新しいクライアントではこれをオフにしようとしました。

編集 多くの掘り下げた後...

  1. SAML2 プロトコルは Microsoft WIF でサポートされておらず、今後もサポートされる可能性があります。

  2. SAML2 プロトコル メッセージは、通常、HTTP POST の本文内のフォーム パラメータ (saml= < saml:Response>< など) です。私の場合、(saml=) の標準パラメータ形式を使用していませんでした。 HTTP POST 本文に直接インライン化されていました。