9

JWT RFCには、次のような複雑な配列を含む問題はないようです。

{
    "email": "test@test.com",
    "businesses": [
        {
            "businessId": "1",
            "businessName": "One",
            "roles": [
                  "admin",
                  "accountant"
            ]
        },
        {
            "businessId": "2",
            "businessName": "Two",
            "roles": [
                  "support"
            ]
        }
     ]
}

トークンの一部として、ユーザーがアクセスできるビジネスのリストと、各ビジネスに対してユーザーが持っているロール (ID の一部) を取得したいので、これは私たちのニーズにとって望ましいシナリオのようです。API の承認ポリシーは、後でそれらのグループを理解し、必要な承認ロジックを適用します。

IdentityServer4 では、クレームがProfileDataRequestContextのIEnumerable<Claim> IssuedClaimsプロパティに追加されることがわかりました。

この複雑なクレーム構造に代わる推奨されるものはありますか? そうでない場合、IdentityServer4 (おそらくいくつかの拡張機能) でその構造を構築する方法はありますか? または、Claim が文字列のみを受け入れるように見えるため、JSON を手動でシリアル化することが唯一の方法ですか?

PS:この質問と、Identity Server の作成者の 1 人が似たようなアンチパターンについて話しているこの質問を見たことがあります。アンチパターンが複雑なクレームの構造またはクレームの「承認実装の詳細」を持つことになるかどうかは不明です。

これに関するアドバイスは素晴らしいでしょう！

アップデート：

いくつかの考えを述べた後、クレームの複雑な階層を持つことは望ましくないことに同意し、各ビジネス ID にロールをプレフィックスする汚いソリューションでこの問題を回避できます。このようなもの：

{
    "email": "test@test.com",
    "roles": [
        "1_admin",
        "1_accountant",
        "2_support"
     ],
     "businesses": [
        "1_One",
        "2_Two" 
     ]
}

そうすれば、単純な構造を維持し、後でクライアントまたは API でクレームを読み取ることができ、それが1名前を持つビジネスの ID でOneあり、ロールadminと を持っていることがわかりますaccount。

これはより良い解決策でしょうか？

4

1 に答える 1

14

クレームはアイデンティティ情報に関するものであり、複雑な許可「オブジェクト」ではありません。ユーザーの ID に基づいて任意の形式でアクセス許可を返す専用のアクセス許可サービスを使用する方がはるかに優れています。

また、トークンの使用中に許可データが変更されないことを願っています。そうしないと、データが古くなってしまいます。

そうは言っても、.NET ではクレームは常に文字列ですが、ClaimValueTypeをIdentityServerConstants.ClaimValueTypes.Json.

于 2016-09-08T04:56:52.683 に答える