問題タブ [sts-securitytokenservice]

Thinktecture.IdentityServer (オンプレミス) .NET 4.5 バージョンを使用しています。構成の問題をデバッグするための支援が必要です。OAuth エンドポイントにアクセスしようとすると、

「HTTP エラー 500.19 - 内部サーバー エラー ページの関連構成データが無効なため、要求されたページにアクセスできません。」

これは設定エラーです:

この構成セクションは、このパスでは使用できません。これは、セクションが親レベルでロックされている場合に発生します。ロックは、デフォルト (overrideModeDefault="Deny") か、overrideMode="Deny" または従来の allowOverride="false" を使用したロケーション タグによって明示的に設定されます。

web.config の問題領域の構成ソースは次のとおりです。

どうやって前に進めばいいのかわからない。私はこの解決策を試しました: http://blog.thinkoriginally.com/2010/02/17/asp-net-config-error-this-configuration-section-cannot-be-used-at-this-path/しかし成功しませんでした

私のアプリケーションは、その場で仮想ディレクトリを作成するだけでなく、それらの仮想ディレクトリで実行される STS 対応の Web アプリケーション用のアプリケーション プールも作成します。アプリケーション プールは、ApplicationPoolIdentity アカウント (IIS APPPOOL\MyAppPool) で実行されます。そして、インストールされた証明書へのアクセスをプログラムで許可する方法を見つけようとしています。

私の最初のアプローチは、WinHttpCertCfg を実行するバッチ ファイルを使用することでした。ただし、このアプローチは、「アクティブ化」されたアプリ プール アカウントでのみ機能します。「アクティブ化」とは、新しいアプリケーションを少なくとも 1 回参照したことを意味します。これが発生するまで、WinHttpCertCfg は常に「ハンドルが無効です」というメッセージを返します。

私が試みた次のアプローチは、ここから得られた解決策に基づいていました。このソリューションは、MMC で証明書を参照して [証明書キーの管理] を選択すると、アプリ プール アカウントが一覧表示されるという意味で機能します。WinHttpCertCfg を実行してアクセス権のあるアカウントを一覧表示しても、新しいアプリ プールが一覧表示されます。

しかし、結局のところ... Webアプリケーションを参照すると、「キーセットが存在しません」というメッセージが表示されます。

私の焦点は、2番目のアプローチを修正することです。これが元のコードへの私の変更です

CRM インスタンスでクレーム ベース認証を構成しました。カスタム STS を使用しています (サンプルはこちらから入手できます) ここで、テスト アプリケーションから Web サービスにアクセスしたいと考えています。誰かがこれの例を持っていますか? Windows認証の場合、同じコードで接続してみました。しかし、もちろん失敗。エラーが発生します：

{"認証エンドポイントの Kerberos が、構成された Secure Token Service で見つかりませんでした!"}

これは接続用のコードです (AD 認証タイプの場合):

クレーム ベースの認証では、UPN (ユーザー プリンシパル名) のみを送信するだけで十分であることがわかりました。しかし、同じエラーが発生します。ユーザー名とパスワードの組み合わせも試しましたが、失敗しました。

...

...

この後のエラーは次のとおりです。The authentication endpoint Username was not found on the configured Secure Token Service!

Thinktecture.IdentityModel.45ライブラリでは、次のようなものを実行して取得できますMicrosoft.IdentityModel.Claims.ClaimsIdentityCollection。

ユーザーがログインして、所属する組織のコンテキストを選択するシステムがあります。各コンテキストは、トークンで使用できるものを表す必要があります (特定のクレームのコレクションを持つ組織ごとに 1 つの ID)。Thinktecture.IdentityServer.45が複数の ID を含むトークンを返すようにするにはどうすればよいですか?

このエラーの意味を誰か教えてもらえますか?
WIF を使用してビルドした STS から取得し始めたばかりですが、ドキュメントが見つかりません。

アクティブフェデレーションとパッシブフェデレーションをサポートするWIFを使用してSTSをセットアップしています。

STSを依拠当事者として使用する複数のサービスがあります。

シナリオがどのように機能し、あるサービス（RelyingParty1など）が別のサービス（RelyingParty2など）のクライアントであり、RelyingParty1（物理的な人/ユーザー）のクライアントがSTS/Idpユーザー名とログインを介して認証する場合に実装されるか知りたいRelyingParty1はRelyingParty2を使用したいと考えています。

RP2はSTSと通信しますか、それともRP1からRP2に有効なトークンが渡されますか？これに必要な特定の構成はありますか？

RP2がSTSと通信してトークン/認証を検証できる/実行する場合（SSOは必須ではないため、毎回チェックすることが望ましい場合があります）、STSはRP1の物理ユーザーをIClaimsIdentity / IClaimsPrincipalとして使用し、RP1のユーザーではないことをどのように認識しますかとして実行されていますか？

クライアントがSTSに接続してSAMLトークンを取得し、それを使用してサービスに対して自己認証するようにしたいのですが、トークンに標準のSAMLトークンよりも多くの情報を含めたいので、トランスポートレベルのセキュリティの使用も避けたいです。 。ある意味では、セッションキーを持つケルベロスチケットと非常によく似ています。

これは可能ですか？

私は Axis2 と壁を使用してクライアントとサービスを作成しています 私が制御するサードパーティの認証システムもクライアントにトークンを発行し、クライアントがサービスに送信する問題は、このトークンを検証する方法がわからないことです。 SAML の範囲外であると言われました サードパーティの認証者に連絡せずに、または公開鍵を使用せずにトークンを検証する方法はありますか

どんな助けでも大歓迎です

AWSSTSがAWSクレデンシャルをアプリに保存しないようにする方法を説明しているAWSSTSページを読んでいます。最終的には、TVM IAMアカウントを持つことで問題を解決しますが、残念ながら問題は残ります。 TVMIAMクレデンシャルを無回答で保存します。

「トークン自動販売機を使用したAWSモバイルアプリケーションのユーザーの認証」のページは次のとおりです：http： //aws.amazon.com/articles/4611615499399490

その上、STSがこれらの懸念にどのように対処し、役立つのか本当にわかりません
。1）TVM IAMアカウントのクレデンシャルをアプリ以外のどこに保存しますか？

2）TVM IAMを盗むことができる場合、そもそも特定のサービスに制限されたIAMアカウントを持つよりもSTSの方が安全ですか？

3）セキュリティ上の理由でTVM IAMアカウントのクレデンシャルを変更した場合、STSはどのようにしてアプリを再デプロイする必要がないようにしますか？

トークンレイヤーを追加すると、アプリにクレデンシャルを配置したり、既存のIAMシステムに付加価値を付けたりしないようにするのに本当に役立つので、私は本当に混乱しています。私は明らかに何かが欠けているに違いありません。

何か助けて、plz？
J

これがセットアップです。STS プロバイダーと 2 つの ASP.NET MVC サイトがあり、どちらも同じ STS プロバイダーを信頼しています。ユーザーはサイト A にアクセスし、STS プロバイダーのパッシブ ログインにリダイレクトされ、適切に認証され、期待どおりサイト 'A' にリダイレクトされます。これはすべてうまくいきます。次を使用して、サイト「A」のコードでトークンと ID を確認できます。

現在、サイト「A」からサイト「B」へのリンクがあり、同じSTS プロバイダーを信頼しています。問題は、サイト 'B' に移動すると、クレーム情報が存在せず、ユーザーが自動的に認証されないことです。STS および WIF のドキュメントによると、次のことが発生するはずです。

「フローは通常どおりに開始され、ユーザーはサイト A の B からページを要求し、トークンを取得するために STS にリダイレクトされます。ただし、このユーザーは、STS サイトで既に認証されています。 STS cookie. これは、STS ページの要求が、ユーザーに資格情報収集用の UI を表示することなく、SecurityTokenService 発行シーケンスの実行に直接つながることを意味します.トークンはサイレントに発行され、B に転送されます.いつもの順番通り。ユーザーが B へのリンクをクリックし、ブラウザーが B から要求されたページを表示した瞬間から、ブラウザーのアドレス バーのちらつきだけで、なんらかの認証がフードの下で行われたという事実が明らかになります。これがシングル サインオン (SSO) の意味です。ユーザーは 1 回だけサインインした経験があり、その瞬間から、システムはユーザーに再度資格情報を要求することなく、他の信頼できるパーティにアクセスできるようになります。」

これを正しく機能させるには、STS プロバイダー、サイト A、またはサイト B で明示的に何を行う必要があるかを知っている人はいますか? STS とサイト「A」は完全に機能していることを思い出してください。サイト「B」が SSO 機能を取得していないだけです。

ありがとう！