問題タブ [component-space]
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.
c# - Web API リダイレクトが機能しない
SAML および SP 開始の SSO を使用してプロジェクトを実装しようとしています。私のプロジェクトは MS Web API を使用しています。
以下は、CompenentSpace を SAML ライブラリとして使用して SAML ハンドシェイクを開始するコントローラーのコードです。
「catch」句について心配する必要はありません。私はそれが何もしないことを知っています。
私が直面している問題は、このメソッドを呼び出すと次の応答が返されることです。
最初の問題についてコンポーネント スペースにメールしたところ、次のような返事が返ってきました。
これは、302 リダイレクトがブラウザに返されることを意味します。たとえば、以下を参照してください。
ブラウザは、エンコードされた SAMLRequest を含むこの URL に対して GET を実行する必要があります。」
ブラウザがリダイレクトするのではなく、この応答を受け取る理由はありますか?
java - Opensaml 検証と ComponentSpace 検証
私はopensamlを使用してSAMLに署名しており、OpenSAMLのSignatureValidatorを使用して正常に検証することもできます.
IdP はコンポーネント スペースを使用して側で検証しますが、同じ SAML と publicCertificate を使用して検証することはできません。
SAML の署名アルゴリズムは RSASHA1 です。ログから、署名のハッシュ値が異なることがわかりました。ログは次のとおりです。
php - CorePHP - SAMLSignOn が失敗しました: base-64 でエンコードされた文字列を XML に変換できませんでした
corePHP を使用して SAML アサーション用の ID プロバイダーをセットアップしました。curl を使用してアサーション リクエストをサービス プロバイダに送信しています。
私の ID プロバイダーは、curl を使用するコア php にあります。
サービス プロバイダーは、asp.net の componentspace saml2.0 を使用して作成されます。
これが私のコードです：
サービス プロバイダーでこのスクリプトを実行すると、次のエラー メッセージが生成されます。
SAMLSignOn が失敗しました: base-64 でエンコードされた文字列を XML に変換できませんでした。
[例外: SAMLSignOn に失敗しました: base-64 でエンコードされた文字列を XML に変換できませんでした。]
[SAMLSerializationException: base-64 でエンコードされた文字列を XML に変換できませんでした。]
私はすでにこの問題に長い時間を費やしてきました。
asp.net - ComponentSpace SAML2.0 ライブラリ: 無効なアルゴリズムが指定されました。(証明書アルゴリズム: RSASHA256)
コンポーネントスペース SAML2.0 を使用して IDP をセットアップしました
サービス プロバイダーもコンポーネント スペース SAML2.0 上にある
証明書アルゴリズム: RSASHA256
AuthRequest なしで SAMLResponse を送信しているため、サービス プロバイダー証明書の詳細はありません。
私たちの側でアサーションを送信すると、これらのエラーが発生します。
CryptographicException: 無効なアルゴリズムが指定されました。
SAMLSignatureException: XML 署名の生成に失敗しました。
asp.net-core - IdP プロキシ - SLO SP 開始
コンポーネント空間の SAML ソリューションに基づいて IdP プロキシを構築しようとしています。
これまで、次の方法でシングル サインオンを処理できました。
- からリクエストを受け取り、パートナーに対してを開始する
SingleSignOnServiceメソッドを追加します( )。AUTHNSPSSOIdPSP-initiated SSO - 結果を
AssertionConsumerService受け取り、フラグをチェックする を追加します。このフラグに基づいて、私が流れているか流れているかを識別し、それに応じて流れを確定しました。SSOIsInResponseToSP-initiated SSOIdP-initiated SSO
次のフロー例を使用して、同じ方法でシングル ログアウトを処理しようとしています。
理論的には、SP によって開始されたログアウトの場合、次のことを達成する必要があります。 1. 単一のログアウト要求を受信する 2. 応答でないかどうかを確認する 3. IdP を識別する 4. ステップ 3 で識別された IdP に Slo 要求を送信する 5ログアウトの成功を示す SP が開始した SLO に応答します。
SP の最後でセッションを破棄することはできますが、IdP セッションを削除することはできません (私はそれを考えています
アタッチされたプロキシ プロセスの 3 番目のステップとして、IdP セッションの削除をトリガーする必要があります)。
「プロトコル的に」欠けているものはありますか？
附属書（InitiateSloAsync方法）：