3

複数の組織とアプリケーションをホストするマルチテナント システムで、組織がシステムでホストされている複数のアプリケーションを使用する可能性がある場合、ユーザーとロール モデルは、単一のユーザーまたはロールが複数のアプリケーションと組織にまたがって存在できるようにする必要がありますか? それとも、ユーザー エンティティを 1 つの組織とアプリケーションのペアに制限し、それらのユーザー エンティティを結び付ける包括的なモデルを定義する必要がありますか?

あれは：

  • ジョン・ドウは人です

  • 彼は ApplicationA と ApplicationB を使用したい

  • 彼は、OrganizationA と OrganizationB という 2 つの異なる会社 (ご容赦ください) で働いています。

ユーザーモデルは次のようにする必要があります。

  1. johndoe@someuniquesuffix は、彼の一意のユーザー名です。これにより、彼は両方の組織の両方のアプリケーションにアクセスできるようになります。

  2. johndoe@applicationa@organizationa は、OrganizationA の ApplicationA に対する彼のユーザー名です。johndoe@applicationb@organizationa は、OrganizationA の ApplicationB に対する彼のユーザー名です...そして OrganizationB でも同じです。次に、アプリ/組織の 4 つのユーザー アカウントすべてが同じ実際の「人物」である John Doe に対応していることを示す「マスター」リストがありますか?

上記と同じシナリオが、ロール スキーマの設計方法にも当てはまります。

助けてくれてありがとう！

4

2 に答える 2

3

IMO、クレデンシャルの各セットを組織に制限する必要があります。さらに、各アプリケーションの機能を有効にして、その組織内のユーザーが各アプリケーションで実行できることを制限する必要があります。つまり、各アプリケーションは独自の承認ロールを管理する必要があります。ジョーが組織Aを離れるが、組織Bで働き続けるシナリオを処理するには、何らかの手段が必要です。

于 2010-08-14T23:46:18.900 に答える
2

個人的には、John Doeが組織Aと組織Bの両方で働いている一人であるということを追跡することは、ほとんどの場合に多くの価値を追加することなく、物事をかなり複雑にすると思います。モデルでAのJohnDoeがBのJohnDoeと同じであることを理解する明確なビジネス上の理由がない限り、私はそれを避けます。すべての組織でユーザーデータベースを維持し、組織全体で一意の名前を処理する必要があり（「John Doeがすでに存在するというのはどういう意味ですか？それは私ではありません！」）、UIモデルをこれに設定します（たとえば、ログイン時にユーザーに尋ねる）今日のAのデータを処理しますか、それともBのデータを処理しますか？）は、重大な問題を追加するだけです。

私の推奨事項の1つの欠点は、OpenIDやOAuthなどのサードパーティの認証システムを使用する場合、複数のテナントを持つ人が異なるIDでログインする必要があることです。例えば。私は自分のグーグルopenIdでログインし、最終的にAのデータにアクセスしますが、Bで作業するには、Twitterアカウントを使用する必要があります。これは、Google IDがすでにAに関連付けられており、Aのみであるためです。

于 2010-08-15T03:20:50.907 に答える