0

SaaS Web アプリ用の認証/承認モジュールが必要で、WIF の外観が気に入っています。問題は、Active Directory を除けば、請求を処理するためのプラグ アンド プレイの方法がないように思われることです。私の考えは、IdentityServerを使用して、ASP.NET メンバーシップ プロバイダーのリポジトリを自分のものに置き換えることです。

トリックは

  • さまざまなお客様と向き合うインターネットアプリ。(したがって、ADFS2は適用されません)。
  • ロールではなく、細かい操作レベルのアクセス許可が必要です。（したがって、ASP.NETメンバーシップは適していません）
  • アプリ内のユーザーに、独自のユーザー サブセットを管理してもらいたい。

私が構築しようとしているビットは、「クレーム サーバー」と呼ばれる下のピンク色のボックスです。

IClaimsServiceを使用すると、新しいユーザーの作成、ロールの作成、ロールへのアクセス許可の割り当て、それらのロールへのユーザーの割り当てなどを行うことができます。私自身のアプリケーションは、IClaimsService にプラグインする管理画面を認証し、サブユーザーなどを作成するためのユーザー権限を認証します。

私の質問は - これは有効なアーキテクチャですか、それとも WIF の要点を完全に見逃していますか?

または、私が見つけていない別のプラグ アンド プレイ オプションがありますか? 車輪の再発明をしなくてよかった！

IdentityServer アーキテクチャ

追加情報

私の Web アプリは SaaS であり、顧客がデータのウォールド ガーデン内に独自のユーザーを作成できるようにする必要があります。

たとえば、システム内に独自のクライアントを持つ採用担当者の競合チームがある採用ソフトウェア プラットフォームを考えてみてください。あるチームが別のチームのデータをピークにすることは許可されていませんが、各チームは独自のユーザーのサブセットを管理および管理できます。多くの異なる企業がプラットフォームを使用している可能性があるため、これを管理する中央の IT 部門/ドメインはありません。すべてセルフサービスです。

私が望むものに近いnetsqlazmanを見てきましたが、Windows Identity Foundation は、新しい顧客を配線し、独自の STS を認証のために接続できるため、長期的なメリットがあるようです。

4

1 に答える 1

1

WIF が長期的に正しい道を示してくれるというあなたの意見は正しいと思います。クレーム ベースの ID が定着し、あらゆるものが収束しつつあります。WIF を使用すると、以前よりもはるかに簡単に実装できます。

私が推奨するのは、可能な限り単純なことから始めることです。それは、最初にクレームを使用してユーザーを認証することです。次に、ユーザー ハンドル (電子メール、user_id など) を、アプリで構築する承認アーキテクチャに関連付けます。メンバーシップ、カスタム データベースなどである可能性があります。

説明するプロビジョニングと自己管理はすべてアプリ固有であり、選択した ID プロバイダーとは関係ありません (たとえば、IdentityServer や WIF と互換性のあるもの: SAML トークン、WS-Federation など)。

この簡単な手順により、時間をかけてより洗練されたソリューションの基盤が準備され、わずかな労力ですぐに価値を提供できるようになります。たとえば、ソーシャル ID を持つユーザーがサイトにログオンできるようにすることができます。アプリで「fiat@mail.com」->「ユーザーを管理できる」と定義します。

時間の経過とともに、それらがさらに外部化できる一般的で反復的な属性であることがわかります (役割など)。次に、あなたが提案したようなものが理にかなっています。

1 つの明確化: ADFSは AD に対してのみ認証しますが、どこからでも属性を取得できます (データベース、LDAP、カスタムなど)。

于 2012-05-14T17:06:01.530 に答える