2009-07-15 2 views
10

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

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

この情報を運ぶためにSAML 2.0アサーションがどのように見えるかの例を教えてもらえますか?

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

答えて

26

あなたのユースケースは、SAML 2.0の機能とはよく分かりません。

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

SAML 2.0の標準的な使用例は、アイデンティティ(アイデンティティプロバイダ)とアサーション(サービスプロバイダ)に依存する他のパーティ(またはパーティ)を主張する一方のパーティに焦点を当てています。アサーションは、アイデンティティプロバイダとサービスプロバイダの間で事前に合意された名前識別子と呼ばれるものを保持します。

これらの名前識別子はほとんど何でも構いませんが、広範には一時的なものと永続的なものの2つのカテゴリに分類されます。一時的な名前識別子は、現在のセッションのコンテキストでのみ有用であり(本質的に「私はこの人物が誰かを知っています」)、プリンシパルの身元を保護するために使用され、ある種の特権アクセスを許可する傾向があります。永続的な識別子は、主張者が主体の身元を明らかにせずに反復的に検証することができる、OpenIDがSOにアクセスするのと同様の方法で不透明にすることができます。 Active Directory UPN(事前に事前に合意することができます)など、より実質的なものです。

あなたの質問に言及しているように、パスワードに関しては、サービスプロバイダ(依拠当事者)はユーザーのパスワードを決して見ません。サービスプロバイダは、認証要求を使用してユーザーをIDプロバイダに渡します。アイデンティティプロバイダは、アイデンティティプロバイダとサービスプロバイダとの間の関係の文脈においてユーザのアイデンティティに関するアサーションを含む応答を用いて、ユーザをサービスプロバイダに返信する。

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

今、ビジネスルールに戻る...それは、次のいずれかのアカウントのリンクや登録あなたが何をしようとしているように私には見えます

- 私はこのようにそれに近づくでしょう:

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

...

OASIS Security Services Technical Committeeは例を含むXMLスキーマの部品の豊富な文書を入手できるzipファイルのダウンロードを持っています。これは、プロトコルとプロファイルのドキュメントを読む価値があります。これは、アイデンティティの会話に関係する関係者間のメッセージの流れを記述しているためです。

多くのプレゼンテーションが浮かび上がっていて、非常に便利です。具体的には、Eve MalerのSAML v2.0 Basicsは、SAML v2.0が解決しようとしていた問題の実現を支援しました。このプレゼンテーションには、そのアサーションの例が含まれています。更新されたプレゼンテーションがあり、saml.xml.orgの追加リソースへのリンクがあります。

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

+0

私のアプリケーションがユーザーの自己偽造アサーションを処理するのを防ぎますか?アサーションはXMLフォームとしてクライアントに送信されますが、誰でも擬似アサーションを作成できます。処理されたアサーションがIDプロバイダによって送信されたことを確認するために、アプリケーションでどのようなセキュリティチェックを実行する必要がありますか? – steven

+0

SAMLスキーマには、秘密または機密とみなされる可能性のある要素のデジタル署名と暗号化の両方がサポートされています。署名は、配信されたデータが損なわれていないことを保証する最も簡単な方法です。また、スキーマには有効期間のサポートが含まれています。確認する必要があり、サポートプロトコルではリプレイ保護について話し合っているため、セキュリティを確保するのに役立ちます。 –

関連する問題