This is a presentation for .NET Lab community online session.
There are many solutions with the microservice design pattern in the world, and these solutions using multiple domains.
Thus services needs a feature of authentication against an identity who request access to resoueces of the service.
15. Service mesh design pattern
2020/8/22
Service mesh control plane
Service mesh data plane
永続化層
クラウド
抽象化
認証認可
構成
ロギング
プロキシ
16. マイクロサービス・エンドポイント・
サービス
2020/8/22
Service mesh control plane
Service mesh data plane
永続化層
Web API
Micro
service
開発
Serverファーム
デプロイ
クラウド
Micro
service
Micro
service
Micro
service
Micro
service
インクリメンタル・ロールアウト
マイクロサービスエンドポイント
本日は、トークンの解析、検証を行う方法やマイクロサービスのサービス間認証の設計のお話をします。
サービスの流量制限やサービスのエンドポイントの定義をAzure API Managementで行う方法やサービスディスカバリーの仕組みをService Fabric Meshで定義する意味などをお話しします。マイクロサービスのサイドカーを作成できれば、マイクロサービスソリューション全体の設計の敷居が低くなりますので、KubernetesでのEnvoy proxyの利用やGoogle Cloud Endpointsで使用するExtensible Service Proxyでの実装も理解できるようになります。
【読む】Friday fiveにも照会されたので自慢しておきますwww
マイクロサービスの認証の設計として、まずマルチブランド認証とサービス間認証の違い説明します。
マイクロサービスは分散システムなので、永続化層はそれぞれのサービス固有のものになります。マイクロサービスが扱うリソースがすべて同一ドメインのリソースの場合は、マイクロサービスの永続化層は同一ドメイン内で管理されています。【クリック】
ドメインのリソースへのアクセスを承認する際の認証は、同一ドメインの場合、一か所で行うことができます。【クリック】
Microsoft 365をリソースとする場合は、Azure Active Directoryで認証が行えるので、Azure Active Directoryのエンドポイントを経由してセキュリティ・トークン・サービスから得られる認証結果であるトークンを使って、Microsoft Graph API経由で同一ドメインのリソースにアクセスすることになります。
この場合、認証はAzure Active Directoryの認証エンドポイントが行い、リソースへのアクセス承認（認可）はMicrosoft Graph APIが行っています。
異なるドメイン・リソースを扱うマイクロサービスの場合、認証は一か所では行えませんから、それぞれのドメインのアカウントが必要となります。【クリック】たとえば、フェイスブックの投稿内容を使ってTwitterにも投稿するとか、Instagramの企業アカウントの投稿をオフィシャルWebサイトに連携させるといったケースです。今回は映画の座席予約なので、本来はその映画館で上映されている映画とスクリーン、および座席をマッチングさせるのですが、オープンなAPIを使ってサンプルを作ります。
この際に、マルチブランド認証ではOAuthなどを使ってそれぞれのアイデンティティプロバイダーに認証を要求します。アクセストークンが返ってくれば、それを使ってリソースにアクセスします。
ここで重要なことは、マルチブランド認証とは認証と認可のドメインが同一で、かつ複数あるということです。これは、多くのブランドがOAuth手順にOpen ID connect手順を包含してアイデンティティ・プロバイダーとしてのサービスをしているから可能な方法です。
OAuthは、認証が正しい場所で行われたかどうかを検証するものではありません。OAuthは認証済みのアイデンティにリソースを公開するための手順を勧告しているものです。サービスが利用者に対してリソースが使えるかどうかを検証するには、アイデンティを確認できた場所がリソースのオーナーからその使用を許可されている場所である必要があります（OAuthではコンフィデンシャル・クライアントといいます）。
各ブランドは、OAuthのフローにOpen ID connect手順を拡張することで、リソースアクセスを要求された場所がコンフィデンシャル・クライアントであることを確認しています。各ブランドはサービス固有のアイデンティティ（AADアプリケーションのClient IDやGCPのサービス・アカウントなど）を使ってID Tokenを一緒に返却する方法を用意しています。
Azure Active Directoryのアカウントの場合は「Microsoft identity platform」にて「OpenID Connect sign-in and token acquisition flow」が用意されています。【クリック】使い方は簡単で、OAuthフローを行う際にScopeに「openid」を入れるだけです。【クリック】
Azure Active Directoryアプリケーションの設定では、「認証」タブの「暗黙の付与」セクションでアクセストークンとIDトークンをチェックしておく必要があります。APIの仕様としてリソースを要求されたら、リソースをサービスする前にID Tokenを検証することをお勧めします。
他ドメインのリソースを利用するサービスを呼び出すアプリケーション側では、各ブランドのクライアントIDや各種Token（アクセス、リソース、ID）を管理することになります。エンドユーザーのアカウントとパスワードについては保管する必要はありませんから、セキュリティの面でもアプリケーションの構築コスト、運用コストを低減させます。
マルチブランド認証の場合は各ブランドのトークンなどを保存して管理することができますが、サービスの利用側がトークンのライフサイクルを管理しなくてはいけません。
ライフサイクルは、アプリケーションが使用するリソースと同じドメインで管理しているセキュリティ・トークン・サービスが発行したトークンであれば長いライフサイクル（IBM cloud, Microsoft AAD, Facebookなど多くは90日）をリフレッシュトークンによって確保できます（それでも90日ごとに再取得し管理する必要があります）。アプリケーションが使うリソースがアプリケーションのドメインに無い場合、リフレッシュトークンによるトークンの更新が90日間保証されるわけではありません。たとえばサービス提供側の都合によりサービスに必要となるスコープが拡張されることもありますし、監査などのプロセスにおいてリフレッシュトークンを取り消す場合もあります。この場合、再度OAuth認証フローを通してアクセストークン/リフレッシュトークンのペアを再取得する必要があります。
このページに既定の有効期間などの情報がありますので参照してください。
このサードカープロキシを稼働させる基盤としてサービスメッシュを構成することで、マイクロサービス単体では困難だったサービスディスカバリ、負荷分散、サーキットブレーカ、メトリクス、遠隔測定などのサービス間通信全体の管理ができるように設計することがService meshデザインパターンです。
Service meshデザインパターンでは、Service mesh control planeがService mesh data planeの指示に従ってサービス基盤を動かします。
この部分の設定をブラウザのGUIで簡単に設定出来たり、インクリメンタル・ロールアウトなどのCD/CIをサポートするなど、各クラウドベンダーがマイクロサービス向けのエンドポイントサービスとしてチューニングしてサービスしています。
データセンターなどのサーバーファームでWeb APIを公開していた時代とクラウドネイティブなマイクロサービスの最も異なる点は、Service meshアーキテクチャとかService meshデザインパターンといった設計が行われる部分です。
サーバーファームでWeb APIやWeb Appを構築する場合、APIの呼び出し頻度やレイテンシなどを制約事項として要件定義などを行います。クラウドネイティブなアプリケーションに求められるスケーラビリティやソリューションの拡張性などが求められていないシステムを無理やりクラウド・リフト&シフトすることはあまり意味がありません。誰かがキャッチーなバズワードで営業するのを目にしたら開発者はそれを諫める方が良いかと思います。
Service meshデザインパターンは、スケーラビリティやソリューションの拡張性などが求められているソリューションを考慮した設計概念です。
Service meshデザインパターンでは、Sidecar proxyをService mesh data planeと言います。
マイクロサービスを設計する場合、これらの機能の実装方法を考慮する必要があります。
クラウドベンダーのサービスを利用しない場合はオープンソースなどで実装します。
まず、Azure Active Directoryの認証に関するプログラムを作成する場合、Microsoft Graph Toolkitを使うと簡単にプログラムを作成することができるのでご紹介します。
本日のサンプルはもっと面倒な作業が必要になるのでこれを使ってません。GitHubからダウンロードしておいてもらう方がいいです。
Microsoft Graph Toolkitは、すでにAzure Active Directoryでアプリケーションを登録している方なら、Visual StudioでASP.NET Web Appのテンプレートでプロジェクトを作成して3行書いてF5を押下すると認証プログラムを動かせる代物だという話がYoutubeで公開されてます。
ASP.NET Core Web Appを作成する場合は「npm install @Microsoft/mgt」でMicrosoft Graph Toolkitのnodeモジュールをプロジェクトのルートにダウンロードします。
前回のサンプルでは、各サービスはサブドメインごとに設計するというお話しをしました。ここでは会員登録のサービスを作ってサンプルソリューションから問い合わせるようにします。
会員登録サービスのSidecar proxyは「サービスディスカバリ」「ヘルスチェック」「ルーティング」「ロードバランシング」「認証と認可」「監視」を機能として持つ必要があります。
Service mesh control planeを含めて、Sidecar proxyの多くは各クラウドベンダーがサービスを提供しています。ここではAzure API Managementの例をご紹介します。
ただし、Service mesh control planeの解説は目的ではないので、Kubernetesを使ったCD/CIについてはまた後日解説を設けます。
The Web Hypertext Application Technology Working Group (WHATWG) はApple Inc., Google LLC, Microsoft Corporation, Mozilla Corporationでステアリンググループを構成する標準化とテストを通じてWebを進化させることに関心を持つ人によるコミュニティ・グループで、WHATWGがCross origin resource sharingをHTML Living Standardとして勧告しました。
HTML Living Standardの2.6 Fetching resourcesの2.6.4 CORS settings attributesとして仕様策定され、Apple、Google、Microsoft、Mozillaのブラウザに実装されています。
Protocolとport、Hostが同じであることがCross origin resource sharingの条件で、マルチドメインで完結するマイクロサービス・ソリューションは、ブラウザでCORSがどのように扱われるかを理解する必要があります。マイクロサービス・エンドポイントを設置しないマイクロサービスのサイドカーはこれに対応する必要があります。
![Profile
2020/8/22
システム構築のプロセス評価、改善、策定、
開発フレームワークの設計、実装管理、プリ
セールスやプロジェクトの立ち上げなど
ブログ
http://blog.processtune.com
プロフィール
Tetsuro Takao on Facebook, Twitter
or http://mvp.Microsoft.com
コミュニティ
.NETラボの運営スタッフ
https://dotnetlab.connpass.com
Microsoft MVP
Developer Technologies
[July 2010 – June 2021]](data:image/gif;base64,R0lGODlhAQABAIAAAAAAAP///yH5BAEAAAAALAAAAAABAAEAAAIBRAA7)