web-dev-qa-db-ja.com

認証と承認のマイクロサービスの設計

背景：

3つの異なるアプリケーションA、B、およびCがあり、それらはすべて同じユーザー詳細を共有しますが、それぞれに認証を実装する必要があり、作業が重複していました。

いくつかの調査の後、私はマイクロサービスの方法を採用し、認証サービスを実装することにしました。このサービスは各アプリのsecretを保存し、ユーザーが特定のアプリにログインしようとしたときにJWTトークンを準備します。これは期待どおりに正常に機能しています。

現在：

ここで、各アプリケーションにロールと権限を持たせる必要があり、あまりカップリングを作成せずにそれを実装する方法を見つけています。現在の状況に関していくつか質問があります。

質問：

  1. 同じサービスに認証ログインを追加するか、rolesテーブルとpermissionテーブルを含む別のサービスを作成する必要があります。

  2. 最終結果は、ユーザーの詳細と権限を定義するペイロードを含むJWTトークンを送信することになるため、たとえば次のようになります。

    {
  uid: 1,
  name: '...',
  email: '...'
  permissions: [{
    'edit': ['post', 'user'],
    'delete': ['post'],
    'read': ['post', 'user'],
    ...
  }]
}

紙の上では、この構造は私には良いようです。クライアント側からの追加のネットワーク呼び出しを節約します。しかし、それは安全で十分な信頼性があるのでしょうか？

PS：実際のアプリケーションを構築するのに十分な経験はありませんが、正しい方向に進んでいることを願っています。

securitymicroservicesauthenticationenterprise-architectureauthorization
3
CodeYogi

承認を確実に外部化する必要があります。実際、外部化された承認管理というパラダイムさえ存在します。

外部化された承認管理では、承認ロジックをアプリのビジネスロジックから分離することを選択します。これを行う理由はさまざまです。

  • メンテナンス
  • 可視性と監査性：コードを理解するよりも、ポリシーを理解する方が簡単です。
  • 拡張性（将来性あり）：EAMを使用すると、承認要件が変更された場合にアプリを書き直す必要がありません。
  • 再利用：複数のテクノロジーとレイヤー（APIからマイクロサービス、ESB、データベースまで）に同じ認証ロジックを適用できます
  • 容易で開発時間：複雑になる可能性のある認証要件を実装するコードを書くよりも、ポリシーを書く方が簡単です。

外部化された許可管理にはさまざまな形式があります。一部のフレームワークにはツールが含まれています。 Spring SecurityまたはMicrosoftクレームベースの承認。テクノロジーに中立なアプローチが必要な場合は、ABAC（ attribute-based access control ）および [〜＃〜] xacml [〜＃〜] 、ABACの実装を調べます。

XACMLアーキテクチャーは、マイクロサービスと統合する/マイクロサービスの前にあるPEPと、事前に設定された一連のポリシーに対する承認要求を処理するPDPを定義します。

詳細については、アーキテクチャ図をご覧ください

XACML Architecture

1
David Brossard