問題タブ [service-provider]

仕様には次のように記載されています。

OASIS Security Assertion Markup Language (SAML) V2.0 のメタデータ

2.4.1.1 要素<KeyDescriptor>

この<KeyDescriptor>要素は、エンティティがデータの署名または暗号化されたキーの受信に使用する暗号化キーに関する情報と、追加の暗号化の詳細を提供します。その KeyDescriptorType複合型は、次の要素と属性で構成されます。

use[オプション]

記述されているキーの目的を指定するオプションの属性。値は KeyTypes 列挙から取得され、値encryptionとで構成されますsigning。

<ds:KeyInfo>[必須]

キーを直接的または間接的に識別するオプションの要素。

私の知る限り、安全なデータを双方向に送信するには、次のものが必要です。

1. 自分の秘密鍵
2. 自分の公開鍵
3. 受信者の公開鍵

SP メタデータで指定する必要があるキーの証明書と、署名と暗号化に同じ証明書を使用できますか?

IdP のベンダーは、いわゆる「メタデータ テンプレート」を提供し、何をどこに記述すべきかを示しました。

関連する部分は次のとおりです（逐語的に）：

私はそうします：

それは動作しません。

したがって、私の知る限り、署名には秘密鍵の証明書を使用し、暗号化には IdP の公開鍵の証明書を使用する必要があります。

私見はそうあるべきです。

私は正しいですか？

新しく作成したサービス プロバイダー (SP)、SAML2.0 消費エンドポイントをテストしたいと思います。

そのために、 TestShibまたはSSOCircleを使用して、テスト ID プロバイダー (IdP) を作成したいと考えています。これらのサービスはどちらも、新しい SP エンドポイントを記述する適切な SP メタデータを提供する必要があります。

Shibboleth をインストールすると、次のパスを使用してこれが実行されることを知っています。

• [私のドメイン]/Shibboleth.sso/Metadata

ただし、生成された結果に対する私の自信は、ファイルの上部にある次のような警告によって揺らいでいます。

これはメタデータの例です。レビューなしでそのまま提供したり、パートナーにリアルタイムで提供したりしないでください。

また、もちろん、Shibboleth をインストールする必要がありますが、これは不可能な場合があります。

では、SP メタデータを作成/生成する最良の方法は何ですか?

コンポーザーパッケージでネイティブの Laravel 対応物を拡張する独自のカスタム FormBuilder および HtmlBuilder クラスを登録しています。'Illuminate\Html\HtmlServiceProvider'ただし、 app.php 構成のプロバイダー配列から手動で削除せずに、実行時にアプリでそれらを認識させるのに苦労しました。

実行時に何らかの形でこれを達成できる必要があります。

1. 実行時に登録済みのサービス プロバイダーをオーバーライドする方法はありますか?
2. そうでない場合、実行時に登録済みのサービス プロバイダーを削除する方法はありますか?
3. これを達成するためのより良い/より効果的/より効率的な方法はありますか?

spring-security-saml-sample コードを使用して Java で SAML2.0 ServiceProvider を実装しています。ログインに成功すると、応答がアプリケーションのルート パス (ウェルカム ファイル) にリダイレクトされます。それを任意のコントローラーにリダイレクトする方法

ありがとう、テジャス

これが SP メタデータの一部です。

参照: OASIS Security Assertion Markup Language (SAML) V2.0 のメタデータ

署名証明書と暗号化証明書の両方で同じ (または異なる) 証明書を選択する利点はありますか?

ここに署名証明書を含める目的は何ですか?

メッセージが https 経由で送信される場合、トランスポート層の暗号化が提供されます。ここに暗号化証明書を含める必要がありますか?