背景
従来のモノリシックアプリケーションからSpring Cloudに変身した友人は、 Spring Cloudの下でマイクロサービスアクセス許可をどのように管理するかを私に尋ねていますか？より合理的に設計する方法は？大規模な観点から、それはサービス許可と呼ばれ、用户认证、用户权限、および服务校验3つの部分に分かれています。
ユーザー認証
従来のモノリシックアプリケーションは、セッションの存在に慣れている可能性があります。 Spring Cloudのマイクロサービスの後、セッションは分散セッションによって解決できますが、結局のところ、それらは最良の戦略ではありません。一部の人々は、 OAuth2でよく知られているOAUTH2と組み合わせたスプリングクラウドセキュリティを実装し始めました。その後、OAUTH 2のAccess Tokenのストレージ問題を最適化し、バックエンドサービスの可用性とスケーラビリティを改善するために、より良いトークン検証方法JWT （JSON Webトークン）があります。ここで強調すべきことの1つは、 OAuth2とJWTがまったく匹敵しないこと、2つの完全に異なるものであることです。
OAuth2是一种授权框架、 JWTは認証プロトコルです
OAUTH2認証フレームワークOAUTH2には4つのロールが含まれています。
OAUTH2には4つの認証モードが含まれています
その中で、OAUTH2の動作プロセスを以下の図に示します。RFC6749から抜粋：
+--------++-------------------------+| | - （a） - 承認リクエスト - > |リソース|| | | | |所有者|| | < - （b） - 承認助成金--- | || | +-------------------------+| || | +--------------------+| | - （c） - 承認助成金 - > |承認||クライアント| | |サーバー|| |<-(D)--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- ----->|リソース|| | |サーバー|| < - （f）---保護されたリソース--- | |+--------+ +-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Spring Cloud OAuth2では、マイクロサービスリソースにアクセスするすべての要求がHTTPヘッダーにトークンを運びます。アクセスされたサービスは、承認サーバーにトークンの有効性を確認するために要求します。このようにして、两次或者更多次リクエストが必要です。すべてのトークンの有効性の検証は、システムの水平拡張のための非常に大きなボトルネックになっている認証サーバーにあります。
JWT認定プロトコル
授权服务器ユーザー情報とAuthorization Scopeをシリアル化し、JSON文字列を配置し、Base64を使用してエンコードし、最後に承認サーバーの秘密キーで文字列に署名してJSON Web Tokenを取得します。
他のすべてのリソースサーバーがRSAの公開キーを保持すると仮定します。リソースサーバーがHTTPヘッダーにトークンを持つようにリクエストを受信すると、リソースサーバーはトークンを取得し、正しい秘密キー署名を使用するかどうかを確認できます（認定サーバーによって署名されているかどうか、つまり署名検証）。検証を通過した後、TOEKNに含まれる有効な検証情報は、脱出後に取得されます。
その中で、主な操作フローチャートは次のとおりです。
+-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- +-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
上記の方法により、サービスベースのユーザー認証を適切に完了できます。
ユーザー許可
誰もが従来のシングルボディアプリケーションの許可ブロッキングでshiroが好きで、非常に使いやすいです。しかし、分割すると、さまざまなAPIにアクセス許可が散在し始めます。 shiroまだ働いていますか？このプロジェクトでは、私はshiroを使用しませんでした。フロントエンドとバックエンドが分離された後、相互作用はトークンで、バックエンドサービスはステートレスであり、フロントエンドボタンがリソースがあり、どこで権限を管理できますか？
抽象とデザイン
柔軟なコアデザインを導入する前に、プレビューコンセプトを紹介しましょう： RBAC （ロールベースのアクセス制御、ロールベースのアクセス制御）。簡単に言えば、ユーザーにはいくつかの役割があり、各役割にはいくつかの許可があります。
RBACは実際には分析モデルであり、主に基本モデルRBAC0（コアRBAC）、役割階層モデルRBAC1（階層RBAC）、ロール制限モデルRBAC2（制約RBAC）、統合モデルRBAC3（RBACを組み合わせます）に分割されています。
コアUML
これは、複数のビジネスシナリオの後の著者の抽象的なRBAC関係図です
クラスの説明
グループ
グループまたはグループ、特定の数のアクセス許可を持つコレクションも、権限のキャリアになります。
子类：ユーザー（ユーザー）、ロール（ロール）、ポジション（ポスト）、ユニット（部門）。ユーザーの特定の構成を通じて、さまざまなビジネスシナリオのグループまたはグループが形成され、ユーザーの許可は、グループまたはグループの親クラスへの承認を通じて取得されます。
許可
特定の数のリソースとの統合、許可もリソースの運送業者になる可能性があります。
リソース
許可に基づいてリソースがあり、リソースのソースには、メニュー（メニュー）、ボタン（アクション許可）、ページ要素（ボタン、タブなど）、データ許可などがあります。
プログラム
関連する許可コントロールのためのレンダリングキャリアであるプログラムは、複数のメニューに取り付けることができます。
一般的なWebプログラムの基本的な構成
モデルとマイクロサービスの関係
スプリングクラウドサービス後のすべてのAPIインターフェイスが上記のResourcesとして定義されている場合、そのような状況を確認できます。
たとえば、ユーザーが追加、削除、修正、チェックの場合、ページはこれを行います。
| ページ要素 | リソースエンコーディング | リソースURI | リソース要求方法 |
|---|---|---|---|
| クエリ | user_btn_get | /api/user/{id} | 得る |
| 増加 | user_btn_add | /API/ユーザー | 役職 |
| 編集 | user_btn_edit | /api/user/{id} | 置く |
| 消去 | user_btn_del | /api/user/{id} | 消去 |
上記のマッピング関係に抽象化した後、フロントエンドとバックエンドのリソースが参照され、ユーザーグループの許可を容易にしやすくなります。たとえば、追加および削除する許可をユーザーに付与します。前端ボタンのディスプレイと隠れを制御するために资源编码が存在するかどうかを確認する必要がありますが、后端では、ユーザーがURIと対応する请求方式を持っているかどうかを均一に傍受して決定する必要があります。
統一許可インターセプトがZuulゲートウェイに配置されているか、特定のバックエンドサービス（フィルター、インテセプター）のインターセプターに配置されているかどうかについては、簡単に実装できます。コードの侵襲性に限定されません。 Zuulを配置するフローチャートは次のとおりです。
Zuulにアクセス許可の統一された傍受がある場合、問題があります。つまり、バックエンドサービスが安全であり、サービスを登録センターでのみ呼び出す必要があります。これには、サービス間の3番目のモジュール、認証が含まれます。
サービス間の認証
私たちは皆、サービスが登録センターを通じてクライアントを見つけた後、リモート手順と直接呼ばれることを知っているからです。生産において各サービスとデリケートなインターフェイスを保護する必要があります。トピックのプロセスは次のとおりです。
著者の実装方法は、Spring CloudのFeignClient Inteceprot （サービストークンに自動的に適用され、現在のコンテキストを渡す）およびMvc Inteceptor （サービストークン検証、現在のコンテキストを更新）に基づいています。
Spring Cloudの機能を組み合わせた後、全体のフローチャートは次のとおりです。
最適化ポイント
APIインターフェイスのセキュリティは、上記のユーザー合法性の検証、ユーザーの許可インターセプト、およびサービス間の認証を通じて保証されますが、 Http访问频率比較的高くなっています。リクエストの数が増えると、慢の問題は特に明白になります。ユーザーの許可キャッシュ、配布とサービス認証情報の混合ストレージ、および定期的なサービス認証トークンの混合ストレージなど、特定の最適化戦略を考慮することができます。
結論
上記はプロジェクトの私の一般的なアイデアです。興味のある友達は私のオープンソースプロジェクトから学ぶことができます。スターへようこそ：
-Gitchina：https：//gitee.com/minull/ace-security（jwt、user permissions）
-github：https：//github.com/wxiaoqi/ace-security
-gitchina：http：//git.oschina.net/geek_qi/ace-gate（サービス認証）
上記はこの記事のすべての内容です。みんなの学習に役立つことを願っています。誰もがwulin.comをもっとサポートすることを願っています。