1

この質問は、私がクレーム アイデンティティ管理についてほとんど知らないことを示しているのかもしれませんが、ここで説明します。

ID にサード パーティの STS を使用し、承認にカスタム クレームを使用するアプリケーション内で WIF を使用する場合 ( CanCreateFooBar のようなアプリケーションに関連する固有のもの)

1) ユーザーを管理するにはどうすればよいですか? つまり、AD やその他のメンバーシップ プロバイダーからのユーザーは特定できますが、内部的に私のシステムでは、それらについて知る必要があり、ID とは関係のないより多くのユーザー情報が必要です (したがって、この情報を利用できるようにすることは本当に意味がありません)。
問題は、システム データ (ID から開始) をスマートな方法で管理および作成するにはどうすればよいかということです。
私が考えている正確なシナリオは、新しい従業員が会社に追加され、システム管理者が特定の役割を持つドメインのユーザーを作成することです。私のシステムはどのようにしてこの事実を認識することができますか? (私はおそらく、システムの管理者にアクションを求めるようにシステムに促したいと思います。

2) これらのユーザーとロールの要求値はどこに保存されていますか? また、それらを変更するにはどうすればよいですか? 理想的には、特定のユーザーとアクションの権限を変更できるようにしたいと考えています。これに関するガイドラインはありますか？

これらはおそらく非常に不十分な質問であることがわかりますが、問題を解決する方法について考えると、複雑な解決策や、多くの重複を必要とする解決策 (つまり、2 つの場所で使用されるものを作成する) を思い付くので、私は確信しています。この問題について正しい方法で考えていないだけです

ありがとう

4

2 に答える 2

4

ご覧のとおり、フェデレーションによってプロビジョニングの必要性が必ずしも軽減されるわけではありません。これは、すぐにはわからない重要な洞察です。

これに対処するには、次のような複数の方法があります。

  1. メタまたは仮想ディレクトリ製品の使用または
  2. 「JIT プロビジョニング」(別名「動的プロビジョニング」または「オンザフライ プロビジョニング」) を使用する。

後者について説明しよう。このソリューションは、ブログでも説明していますには、IP-STS と RP-STS の 2 つの STS が含まれています。1 つ目は、ユーザーのみを認証します。2 つ目はアプリケーションに固有であり、そのシステムのユーザーを承認するために必要なクレームを認識します。IP-STS は、これらのアプリケーション固有の属性を発行できません。発行すると、企業のディレクトリ サービスがあらゆる種類のアプリケーション固有の情報で混乱することになります。代わりに、そのストアで維持され、IP-STS によって発行されるユーザーの属性は、一般的な性質のものであり、ユーザーが使用しているアプリケーションに関係なく、ユーザーに適用されます。IP-STS に対して認証を行い、そこから ID のみのクレームを取得した後、トークンは RP-STS に渡されます。このトークン サービスは、アプリケーションと密接に結合されています。ユーザーがさまざまなリソースにアクセスするために必要なクレームを認識します。ID のみのクレームを、このアクセス制御の決定を行うために必要なものに変換できます。したがって、RP-STS は、ID 関連のクレームをアプリ固有のクレームにマップするクレーム トランスフォーマーです。

RP-STS はどのようにユーザーをプロビジョニングしますか? 上記の例のように、新しい従業員が作成されたとします。ユーザーがアプリにアクセスすると、RP-STS にバウンスされます。彼はそこにログインしないため、IP-STS にバウンスされます。システム管理者が彼のアカウントを作成したので、彼はログインできるようになり、ブラウザは彼を RP-STS に戻します。RP-STS はトークンをクラックし、ユーザー ID (電子メール、PPID など) を取得して、ユーザーが誰であるかを認識していないことを確認します。したがって、RP-STS はユーザーをプロビジョニングします。これは、たとえば Web ページを表示することによって行われます。RP にアクセスするときに、そのユーザーの役割を判別するのに役立つ情報を収集する場合があります。この後、ユーザーがプロビジョニングされます (つまり、ユーザーのクレーム値を含むレコードがデータベースに作成されます)。RP-STS はアプリケーションに固有のトークンを発行し、アプリケーションをそこにリダイレクトします。アプリケーションは、彼がプロビジョニングされたばかりであることを知りません。いつものようにクレームを使用するだけです。(JIT プロビジョニングと呼んだ理由がわかりますか?)

ユーザーのプロビジョニング後に状況が変化した場合はどうなりますか? わかった。これを想像してみてください: ユーザーは何年も前にディレクトリ ストアで作成され、RP-STS で前述のようにプロビジョニングされ、システムを長い間快適に使用しています。次に、アプリケーションのユーザーが新しい利用規約 (T&C) に同意することを要求するポリシーの変更があります。次回ユーザーがアプリにログインすると、RP-STS にリダイレクトされ、IP-STS にリダイレクトされ、認証されて RP-STS に戻されます。その時点で、ユーザーが新しい T&C に同意する必要があることを認識し、ユーザーに Web ページを表示して同意を得ます。その後、RP-STS はセキュリティ トークンを発行し、ユーザーをアプリにリダイレクトします。いつものように、アプリはクレームを処理し、アクセスを承認するために必要なことを行います。それは知りませんし、しません」ユーザーが「再プロビジョニング」されただけであることは気にしません。または、ILM (現在は FIM と呼ばれています) などの製品を使用して、アイデンティティ ストア (つまり、社内ディレクトリ) と RP-STS のクレーム ストアの間で変更を同期することができます。システムによっては、このようなバック チャネル同期を行う製品の方が適している場合があります。

ところで、これらは「不自由な」質問ではありません! 非常に複雑な問題に対する深い思考と知的な反省を反映した非常に鋭い質問があります。あなたが答える必要がある他のものは次のとおりです。

  • アプリケーションの管理者はどのようにポリシーを更新しますか (T&C を変更するなど)? どの UI/API を作成する必要がありますか? UI は、IP-STS のポリシーを管理するために使用されるものと統合されていますか?
  • このようなシステムが機能するためには、どのような信頼関係が必要なのでしょうか?
  • サブジェクトがパッシブ プロファイルを使用していない場合はどうなりますか? 彼がアクティブなプロファイルを使用している場合、および/または UI がない場合はどうなりますか?
  • 鍵はどこに、どのように配置されていますか? これらのキーを使用するには、どのようなアクセス許可が必要ですか? それらはどのように改訂、配布され、有効期限が近づいたときにシステム管理者にどのように警告されるのでしょうか?

このようなものは、ユーザー グループのミーティングや会議で簡単にデモできますが、実際には非常に高度なものです。他に質問がある場合は、ここに投稿するか、私に直接連絡してください。

于 2009-12-11T18:34:06.747 に答える
1

1）ユーザーを管理していません。実際にはそうではありません。IClaimsIdentity を取得し、それを承認のソースとして使用するだけです。私の意見では、主張をしなくても済むのであれば、主張を主張するべきではありません。主張は、ユーザー情報のソースであるべきです。

クレームに基づいて構築する場合は、クレーム ID から一意の参照を取得します。たとえば、電子メール アドレスまたは ppid/署名キー OU ハッシュを使用し、それを使用して独自のデータベースを構築し、独自の情報を追加します。

ただし、新しい SAML トークンが発行され、アプリケーションで解析されるまでは、サード パーティの ID メタベースの変更がシステムに影響を与えることはありません。

2) クレーム値は、保存しない限りどこにも保存されません。それをアクセス許可に変換する方法はユーザー次第ですが、通常はクレーム変換を実行して、外部クレームを取得し、アクセス許可に使用するアプリケーションの内部クレームにマップします。クレームは外部プロバイダーからのものであるため、それらを変更することはできません。それらのプロバイダーに接続することはできません。

于 2009-12-10T23:20:17.193 に答える