ジュネーブフレームワークでのカスタムクレームと、ユーザーがアプリを「同期する」方法

Question

たぶん、この質問は、私が請求のアイデンティティ管理についてどれほど知らないかを強調していますが、ここには行きます。

アイデンティティにサードパーティのSTSを使用し、認可にカスタムクレームを使用するアプリケーション内でWIFを使用している場合（CanCreateFOOBARのようなアプリケーションと特定のアプリケーション）

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

2）保存されているユーザーと役割の請求値はどこにあり、どのようにそれらを変更できますか？理想的には、特定のユーザーとアクションの境界を変更できるようになりたいです。これに関するガイドラインはありますか？

これらはおそらく非常に足の不自由な質問であることがわかりますが、複雑なソリューションや多くの複製を必要とするソリューションで問題を解決する方法を考えると（つまり、2つの場所で使用されるものを作成します）、確かに私は確かにmこの問題について正しい方法で考えていない

ありがとう

Answer 1

1）実際にはユーザーを管理していません。あなたは単にiclaimsidentityを取り、それを許可のソースとして使用します。私の意見では、あなたがそれを行わずに逃げることができれば、あなたは請求を続けるべきではありません - クレームはあなたのユーザー情報のソースでなければなりません。

クレームに基づいて構築する場合は、クレームアイデンティティから一意のリファレンスを取得し、電子メールアドレスまたはPPID/署名キーOUハッシュを使用して、それを使用して独自のデータベースを作成し、独自の情報を追加します。

ただし、システムは、サードパーティのアイデンティティメタベースの変更がなくなることはありません。新しいSAMLトークンが出版され、アプリケーションで解析されるまで。

2）請求値は、保存しない限り、どこにも保存されません。それを許可にどのように変換するかはあなた次第です - しかし、一般に、あなたはあなたが外部のクレームを取り、それらを許可に使用するアプリケーションの内部請求にマッピングするために請求変換を実行します。クレームは外部プロバイダーからのものであるため、それらを変更することはできません。これらのプロバイダーとは関係ありません。

Answer 2

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

これに対処するには、以下を含む複数の方法があります。

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

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

RP-STはどのようにユーザーを提供しますか？上記の例のように、新しい従業員が作成されたとします。ユーザーがアプリにアクセスすると、RP-STにバウンスされます。彼はそこにログインされないので、彼はIP-STにバウンスされます。 SYS管理者は彼のためにアカウントを作成したため、彼はログインすることができ、彼のブラウザは彼をRP-STに戻します。 RP-STはトークンをクラックし、ユーザーID（電子メール、PPIDなど）を取得し、ユーザーが誰であるかがわからないことを確認します。したがって、RP-STはユーザーをプロビジョニングします。たとえば、Webページを表示することでこれを行います。 RPにアクセスするときにそのユーザーの役割を決定するのに役立つ情報を収集する可能性があります。この後、ユーザーはプロビジョニングされ（つまり、彼のクレーム値を含むデータベースにレコードが作成されます）、RP-STはアプリケーションに固有のトークンを発行し、そこに彼をリダイレクトします。アプリケーションは、彼がちょうどプロビジョニングされたことを知りません。常にそうであるように、クレームを使用します。 （なぜ私はそれをjitプロビジョニングと呼んだのかをご覧ください？）

ユーザーがプロビジョニングされた後に状況が変わる場合はどうなりますか？わかった。これを想像してください：ユーザーは何年も前にディレクトリストアで作成され、上記のRP-STで説明されているようにプロビジョニングされ、彼は長い間システムを喜んで使用しています。次に、アプリケーションのユーザーが新しい条件（T＆C）を受け入れることを要求するポリシー変更があります。次回ユーザーがアプリにログインすると、彼はRP-STS、IP-STにリダイレクトされ、認証され、RP-STにバウンスされます。その時点で、ユーザーは新しいT＆Cを受け入れる必要があることに気付くので、ユーザーにWebページを表示し、同意を得ることができます。その後、RP-STはセキュリティトークンを発行し、彼をアプリにリダイレクトします。アプリは、いつものように、クレームを処理し、アクセスを承認するために必要なことを行います。それは知らないし、ユーザーがただ「再生成された」だけであることを気にしません。または、ILMなどの製品（またはFIMが現在呼ばれているFIM）などの製品を使用して、IDストア（つまり、コーポレートディレクトリ）とRP-STSのクレームストア間で変更を同期させることができます。システムに応じて、このようなバックチャネルの同期を行う製品がより適切かもしれません。

ところで、これらは「ラメ」の質問ではありません！非常に複雑な問題に関する深い思考とインテリジェントな反省を反映する非常に鋭い質問があります。あなたが答える必要がある他の人は次のとおりです。

• アプリケーションの管理者は、ポリシーをどのように更新しますか（たとえば、T＆CSを変更します）？どのUI/APIを作成する必要がありますか？ UIはIP-STSのポリシーを管理するために使用されるものと統合されていますか？
• このようなシステムを機能させるには、どのような信頼関係が存在しなければなりませんか？
• 被験者がパッシブプロファイルを使用していない場合はどうなりますか？彼がアクティブなプロファイルを使用している場合、および/またはUIがない場合はどうなりますか？
• キーはどのように、どこにありますか？これらのキーを使用するには、どのような許可が必要ですか？彼らはどのようにrevedされ、配布され、SYS管理者が期限切れにしようとしているときにどのように警告されていますか？

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