ユーザー名/パスワードを使用した SAML アサーション - メッセージは実際にはどのようなものですか?

Question

SAML 2.0 アサーションを作成する必要があるのですが、XML が実際にどのようなものであるべきかを見つけるのに苦労しています。ドキュメントのほとんどは、メッセージに関するものではなく、特定のツールの使用に関するもののようです。さまざまな可能性を備えたスキーマはありましたが、関連するメッセージが実際にどのように見えるかを示す例が見つかりません。

ビジネスルールには次のように書かれています。共有 ID を作成するために、ユーザーはシステム A にシステム B 上のユーザー名とパスワードを伝えます。システム A は、この情報 (一部の人口統計とともに) をシステム B に伝達する必要があります。システム B は情報を検証し、このユーザーを参照するために使用できる一意の識別子を返します。

誰かがこの情報を伝える SAML 2.0 アサーションがどのようなものになるかの例を教えてくれませんか?

FWIW、私は C# を使用していますが、サードパーティ ツールの使用を妨げる方法で XML を渡す必要があります。

Answer 1

あなたのユースケースが SAML 2.0 の動作とまったく同じであるかどうかはわかりません。

ビジネス ルールとして説明したものは、実際にはアクセス管理ではなく、アイデンティティ プロビジョニングのユース ケースのように見えます。

標準 SAML 2.0 の使用例は、アイデンティティを主張する一方の当事者 (アイデンティティ プロバイダー) と、それらのアサーションに依存するもう一方の当事者 (サービス プロバイダー) に焦点を当てています。アサーションにはいわゆる名前識別子が含まれており、その使用はアイデンティティ プロバイダーとサービス プロバイダーの間で事前に合意されています。

これらの名前識別子はほとんど何でも可能ですが、大きく 2 つのカテゴリに分類されます。一時的かつ永続的。一時的な名前識別子は、現在のセッションのコンテキストでのみ役に立ちます (そして基本的には、「この人が誰であるかを知っています」と言うだけです)。また、ある種の特権アクセスを許可しながらプリンシパルの ID を保護するために使用される傾向があります。永続的な識別子は、（SO へのアクセスに OpenID が使用されるのと同様の方法で）不透明にすることができ、アサーティング当事者は、アサーティング当事者と依存当事者の間で動的だが安定した共有識別子を維持しながら、アイデンティティを開示することなくプリンシパルのアイデンティティを繰り返し検証できます。 Active Directory UPN など、より実質的なもの (事前に事前に合意することができます)。

パスワードに関しては、質問で述べたように、サービス プロバイダー (依拠当事者) がユーザーのパスワードを見ることはありません。サービス プロバイダーは、認証リクエストを使用してユーザーを ID プロバイダーに引き渡します。ID プロバイダーは、ユーザーをサービス プロバイダーに応答で送り返します。認証が成功した場合、その応答には、ID プロバイダーとサービス プロバイダーの間の関係のコンテキストにおけるユーザーの ID に関するアサーションが含まれます。

あなたの質問の文脈で言えば、重要なことは、SAML 2.0 では、ローカルの「アプリケーション」ユーザー アカウントを作成したり、そのローカル ユーザー アカウントをフェデレーション ID にリンクしたりする方法が提供されていないということです。これは SAML 2.0 が解決しようとする問題ではありません。

さて、ビジネスルールの話に戻りましょう...

あなたがやろうとしていることは、アカウントのリンクまたは登録のいずれかであるように私には思えます。私なら次のようにアプローチします。

• ユーザーがアプリケーションにアクセスし、ボタンをクリックして ID プロバイダーからの ID を使用します
• アプリケーションは認証リクエストを生成し、その認証リクエストを伝えるアイデンティティ プロバイダーにユーザーを誘導します。
• ID プロバイダーは、ユーザーをログインさせるか、ユーザーが既存の ID セッションを持っている場合はそれを再利用します。IdP は、ユーザーに関するアサーションを含む応答メッセージを生成します。あなたの場合、このアサーションには少なくとも永続的な名前識別子が含まれている必要があります。ID プロバイダーは、応答メッセージを伝えてユーザーをアプリケーションに戻します。
• アプリケーションは応答メッセージを処理します。渡された永続識別子のマッピング エントリが存在する場合、ユーザーはそのマッピングから認識され、ローカル アプリケーション ユーザーとしてログインします。マッピング エントリが存在しない場合、ユーザーはローカルにログインするよう求められ、ローカル ログインが成功するとマッピング エントリが作成されるか、ユーザー アカウントが自動的に作成され、ユーザーは追加情報 (名前、電子メール アドレス) の入力を求められます。など）「企業」の使用例では、アカウントの自動リンクや作成は許可されておらず、事前にマッピングが存在している必要があります。

メッセージの内容はというと…

の OASISセキュリティサービス技術委員会 には、例を含む XML スキーマの各部分に関する広範なドキュメントを含む zip ファイルのダウンロードが用意されています。また、プロトコルとプロファイルのドキュメントには、ID の会話に関与する当事者間のメッセージの流れが説明されているため、これらを読むことも価値があります。

非常に役立つと思われるプレゼンテーションが多数存在します。具体的には、 SAML v2.0の基本 Eve Maler の著書は、SAML v2.0 が解決しようとしている問題を認識し始めるのに役立ちました。このプレゼンテーションには、アサーションがどのようなものであるかの例が含まれています。更新されたプレゼンテーションと追加リソースへのリンクがあります。 saml.xml.org.

ただし、あなたのユースケースは SAML 2.0 が行おうとしているものではないようなので、これが役立つかどうかはわかりません。必要に応じて属性と拡張機能をリクエストとレスポンスに追加できますが、多くの ID プロバイダーがこれらの属性とレスポンスを使用して何かを行っているのは見当たりません。