11

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

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

この情報を運ぶ SAML 2.0 アサーションの例を教えてください。

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

4

1 に答える 1

27

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

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

標準の SAML 2.0 ユース ケースは、ID を主張する一方の当事者 (ID プロバイダー) と、それらの主張に依存するもう一方の当事者 (または複数の当事者) (サービス プロバイダー) に焦点を当てています。アサーションは名前識別子と呼ばれるものを保持し、その使用は ID プロバイダーとサービス プロバイダーの間で事前に合意されています。

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

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

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

さて、ビジネス ルールに戻ります...

あなたがしようとしているのは、アカウントのリンクまたは登録のいずれかのように見えます-私は次のようにアプローチします:

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

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

OASIS Security Services Technical Committeeは、例を含む XML スキーマの各部分の詳細なドキュメントを含む zip ファイルをダウンロードできます。プロトコルとプロファイルのドキュメントも読む価値があります。これらは、ID の会話に関与する当事者間のメッセージの流れを説明しているためです。

非常に役立つプレゼンテーションがたくさんあります。特に、 Eve Maler によるSAML v2.0 Basicsは、SAML v2.0 が解決しようとしている問題を理解するのに役立ちました。このプレゼンテーションには、そのアサーションがどのように見えるかの例が含まれています。saml.xml.orgには、更新されたプレゼンテーションと追加リソースへのリンクがあります。

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

于 2009-07-17T09:15:16.520 に答える