web-dev-qa-db-ja.com

ASP.netCOREにアップグレードする場合のShibboleth404

SecureAuthを使用してShibbolethをIISサーバーでシンプルなindex.htmlをホストし、後でシンプルなASP.net MVC 4アプリをホストすることで、どちらもうまく機能するようになりました。

ただし、今日は、アプリが新しいASP.netCOREアプリを指すようにするだけです。私がしたのはIISのディレクトリを変更することだけで、特別なことは何もありませんでした。サーバーに.NETCoreホスティングをインストールしましたが、SecureAuthで再認証する必要があるまで、動作します（アプリは正常に実行され、読み込まれます）。その場合、 https://mywebsite.com/Shibboleth.sso/SAML2/POST の結果は200ではなく404になります。最初に考えたのはWebConfigで、これは非常によく知っています。少しについて。 ここ は古いもので、 ここ は新しいもので、どちらもVisual Studio2015の既定のテンプレートから変更されていません。

続行する必要のある追加のサーバー構成がありますか、または未定義の動作をトリガーしているそのWebConfigに奇妙なハンドラーがありますか？シボレスは私にとって新しいので、気楽に行ってください！

編集：いくつかの追加の詳細...オンIISバージョン8 ISAPIとCGIの制限、ISAPIフィルター、およびハンドラーマッピングを構成しました（[要求がマップされている場合にのみハンドラーを呼び出す...]チェックボックスをオフにします）。 ）Shibboleth DLLを指すようにします。私のShibboleth構成ファイルはすべて、古いアプリでも正常に機能したため、どのようにそれらであるかわかりません。

iis.netiis-8asp.net-mvcshibboleth
2
TheSmartWon

Web.configファイルに、ハンドラー部分などのシボレス構成が含まれていないことに気付きました。

      <add name="ShibbolethEndPoints" path="*.sso" verb="*" modules="IsapiModule" scriptProcessor="C:\opt\shibboleth-sp\lib64\shibboleth\isapi_shib.dll" resourceType="Unspecified" preCondition="bitness64" />

初期設定（IIS UIを使用）を使用してハンドラーを追加）を実行すると、この行がweb.configファイルに追加されました。

後でアプリケーションの新しいバージョンをデプロイすると、web.configが上書きされ、404エラーが発生します（実際、アサーションコンシューマーサービスのURLを理解するものがないため）

だからあなたの場合あなたがしたのは

  • 新しいアプリケーションを新しいフォルダーにデプロイしました（質問でリンクされている「new」web.configを使用）
  • 既存のサイトを新しいフォルダにポイントしました

その場合、デプロイされたWebサイトでハンドラー構成が欠落している可能性があります。

（ISS UIを使用して）フィルターを再度追加し、生成されたハンドラー構成をプロジェクトのweb.configにコピーすることをお勧めします（再度失わないようにするため）。

IIS、シボレス、およびケストレル

これはあなたの質問に対する直接の答えではありませんが、彼らがどのように相互作用しているかについての簡単な要約です（全体像-さらにトラブルシューティングに役立つかもしれません）

'通常の' ASP.NETアプリケーションとの主な違いは、IISは、ほとんどがKestrelの前にあるリバースプロキシであるということです。

ただし、これは実際にはShibbolethフローには影響しません。通常どおりwww.example.com/ressourcesを保護するようにshibbolethを構成したと仮定します（asp.netコアに固有のものはありません）

Www.example.com/ressources/index.htmlをリクエストした場合：shibbolethはリクエストをインターセプトし、IDPで認証フローをトリガーします

後でwww.example.com/ressources/index.htmlにリダイレクトされたとき（IdPによって識別され、shibboleth ACSによって認証された後-言い換えると、今回はリクエストが有効なshibbolethセッションCookieとともに返されます）

  • shibbolethは引き続き要求をインターセプトし、セッションが有効であることを確認してから、IISに転送します。
  • 次に、IIS 'リバースプロキシ'からKestrelへ
  • Kestrelは、要求されたリソースを提供します（アプリケーションが、ShibbolethがHTTPヘッダーで渡すIDを受け入れると想定しています）。
2
EnjiLenin

私が見つけたところによると、.NET Coreは、IIS（プロキシとして）の使用方法とマネージコードが利用できないため、Shibbolethではうまく機能しません。 。ShibbolethはIIS内でISAPIフィルターとして実行され、.NETCoreアプリケーションは独自のKestrelWebサーバー内で実行されている可能性が高いため、これは機能しません。アドレスが http：//。 ../Shibboleth.sso/login Kestrelのコンテキストには存在しません。

1
icastel