認可サーバーからダウンストリームマイクロサービスにユーザー役割をレプリケートするにはどうすればよいですか。

Question

JWTトークンを生成する認証サーバーを使用するアプリケーションを実装する必要があります。これらのトークンには、ユーザーが異なるリソースへのユーザーアクセスを許可するために付与される役割が含まれます。このセキュリティが追加されるゲートウェイもあります。

私の質問は、ユーザーの役割と内部マイクロサービス間のセキュリティに関するものです。

ユーザーが作成されると、役割のセットが付与され、後で別の役割が付与されるか、後で新しい役割が追加される可能性があります。このすべての情報は、Authorization Serverに保管する必要があります。しかし、この情報は他のマイクロサービスにどのように複製されていますか？ Spring Securityのようなフレームワークを使用してエンドポイントを保護する場合、異なるURLに必要なロールを追加する場合、ダウンストリームマイクロサービスのセキュリティ設定にユーザロールをハードコードする必要がありますか、承認サーバー？

アーキテクチャはパブリックネットワークでAPIゲートウェイを使用し、内部のサービスディスカバリと通信してさまざまなマイクロサービスを検出します。これらはまた、サービスディスカバリを通じてお互いを見つける。私はルーティングのためにZuulを使用します。このような状況では、内部ネットワーク内の通信も保護する必要がありますか？承認のためにSpring Securityを使用するには、ユーザロールを取得するためにJWTトークンを渡す必要があることを理解しています。しかし、そうでなければ必要でしょうか？クライアントからゲートウェイへのHTTPSとプライベートネットワーク内での安全でないHTTPを使用すれば十分でしょうか？

Answer 1

多くのオプションがあります。

これらのうちの1つは、spring-security-oauth2をスプリングセキュリティと組み合わせて使用​​することができることです。この設定では、次の2種類のアプリケーションを区別します。

• 認証サービス（AS） - このサービスは、クライアントを認証するためのアクセストークンを発行して検証します（パスワード許可や認証コードなどを使用）。
• リソースサービス（RS） - リソースに対するCRUD操作のためのREST APIを公開します。エンドポイントは保護されています。 RSは、アクセスを許可するためにASと通信します。

リソースサーバーでは、通常、スタンドアロンアプリケーションと同様にSpring Securityを使用して構成します。以下は非常に簡単な例です。ここで

は、保護されたエンドポイントとRESTコントローラーのコードです：

@PreAuthorize("hasRole('READ_BOOK')") 
@GetMapping(value = "/books/{id}") 
public ResponseEntity<Book> getBook(@PathVariable("id") String id) { 
    ... 
    //retrieves book details if you have role READ_BOOK 
} 

@PreAuthorize("hasRole('WRITE_BOOK')") 
@PostMapping(value = "/books") 
public Book createBook(@RequestParam("title") String title) { 
    ... 
    //creates a book if you have role WRITE_BOOK 
} 

あなたは例外とモノリシックアプリケーションを書いているかのようにセキュリティ設定が見えるということ：

• 必要になります設定に@EnableResourceServer注釈を追加してください。
• RemoteTokenServicesのインスタンスを構成します。このサービスのタスクは、指定されたトークンを認可サーバーに対して検証し、ユーザーの役割を取得します。

ASは、ワークフローOAuth2に基づいてアクセストークンを発行します。これらのトークンは、保護されたエンドポイントにアクセスするためにクライアントによって使用されます。

小さなPoC（プルーフオブコンセプト）設定をしました。ここでは、すべての操作を示す2つの簡単なアプリを作成しました。それはhereであり、質問、提案、PRをお寄せください。完全なソースコードは、より多くの説明とともにバンドルされています。

ただし、この設定によっては、サービス間の通信が多すぎる可能性があります。私は、APIゲートウェイがリソースサーバーとして機能するより複雑な設定を見てきました。ユーザーが十分な資格情報を持っていれば、必要な詳細で要求を充実させ、基本的にゲートウェイを信頼するダウンストリームサービスに要求を渡します。