shiro实现身份验证_微服务中的身份验证和授权如何实现

shiro实现身份验证

When moving to microservices, you will come to the conclusion that securing the microservices needs to be tackled in a different way compared to a monolithic application.

转向微服务时，您将得出结论，与单片应用程序相比，需要以不同的方式解决保护微服务的问题。

While designing the solution, questions like “Where and how do I implement authentication and authorization?” and “How do I authorize users to specific actions?” can popup. In this article, a solution will be introduced to these questions.

在设计解决方案时，诸如“我在哪里以及如何实现身份验证和授权？ ”和“如何授权用户执行特定操作？ 可以弹出。 在本文中，将为这些问题介绍一种解决方案。

First, the differences between authentication and authorization will be explained. Secondly, OpenID Connect and OAuth2 will be introduced as solutions for centralized authentication and authorization for microservice architectures. Lastly, there will be two implementation choices explained for authorization.

首先，将说明认证和授权之间的区别。 其次，将引入OpenID Connect和OAuth2作为针对微服务架构的集中式身份验证和授权的解决方案。 最后，将解释授权的两个实现选择。

身份验证和授权之间有什么区别？ (What are the differences between authentication and authorization?)

When talking about securing applications, the terms authentication and authorization will pop up. While the terms are used interchangeably, they represent different purposes in the spectrum of securing applications.

在谈论保护应用程序安全时，将弹出“身份验证和授权”一词。 虽然这些术语可以互换使用，但它们在保护应用程序范围内代表了不同的目的。

When talking about authentication, it is the process of verifying the identity of the entity he/she/it claims to be. When talking about authorization, it is the process of verifying if the entity is authorized to access specific information or is allowed to execute certain actions.

在谈论身份验证时，这是验证他/她/所声称的实体的身份的过程。 在谈论授权时，它是验证实体是否被授权访问特定信息或被允许执行某些动作的过程。

In regards to the total security flow, both principles fit in and the combination could still make a request fail. In the rule, authentication comes first, authorization second. When a user is authenticated but not authorized, the request will still fail.

关于总的安全流程，两个原则都适用，并且组合仍然可能使请求失败。 在规则中，身份验证首先，授权第二。 当用户通过身份验证但未经授权时，请求仍将失败。

OpenID Connect和OAuth (OpenID Connect and OAuth)

In a distributed system architecture like microservices, implementing authentication and authorization on the traditional way are not possible. With the monolithic architecture approach, often signing sessions are stored in-memory or a distributed session storage to share sessions between instances of the monolithic application.

在像微服务这样的分布式系统架构中，无法以传统方式实现身份验证和授权。 使用单片架构方法，经常将签名会话存储在内存中或分布式会话存储中，以在单片应用程序实例之间共享会话。

In-Memory storage of different applications can not be shared since microservices are separate isolated applications. Centralizing and sharing the distributed session storage is as well discouraged. This creates tight coupling between the microservices and opens the door to leak logic between microservices.

由于微服务是单独的隔离的应用程序，因此无法共享不同应用程序的内存中存储。 不建议集中和共享分布式会话存储。 这在微服务之间建立了紧密的耦合，并为微服务之间的泄漏逻辑打开了大门。

With keeping the microservice architecture in mind, each microservice should be solely responsible for its single piece of business logic, whether that is a small piece of logic or a bounded context. Authentication is in this case a cross-cutting concern and shouldn’t be part of the microservice itself.

牢记微服务架构，每个微服务应独自负责其单个业务逻辑，无论是很小的逻辑还是有限的上下文。 在这种情况下，身份验证是一个跨领域的问题，不应成为微服务本身的一部分。

A widely used solution for this problem is to implement a separate identity server. This service is responsible hosting centralized authentication and authorization. There are several solutions for this, like WSO2 Identity Server (Java), IdentityServer4 (.NET) and OAuth2orize (Node.js). All of these frameworks support authentication and authorization by using OpenID Connect and OAuth2.

针对此问题的一种广泛使用的解决方案是实现单独的身份服务器。 该服务负责托管集中式身份验证和授权。 有多种解决方案，例如WSO2身份服务器(Java)， IdentityServer4 (.NET)和OAuth2orize (Node.js)。 所有这些框架都通过使用OpenID Connect和OAuth2支持身份验证和授权。

什么是OpenID Connect？ (What is OpenID Connect?)

OpenID Connect is an authentication protocol that is a simple identity layer on top of OAuth2. It allows clients to identify clients to verify the identity of a user by an external authorization server like Google, Facebook or a embedded login system in the identity server.

OpenID Connect是一种身份验证协议，它是OAuth2之上的简单身份层。 它允许客户端识别客户端，以通过外部授权服务器(例如Google，Facebook或身份服务器中的嵌入式登录系统)来验证用户的身份。

How would the flow look like? A user requests access to an application. The application determines that the user is not authenticated yet and redirects the user to the identity server. The user authenticates with the identity server. The identity server sends on successful authentication an access token/ID token to the user. This token is signed by cryptographic keys. The user can authenticate with this token at the application. The application validates the signed key by checking if it is signed by the identity server by checking the public cryptographic key. If this is the case, the user is successfully authenticated!

流程看起来如何？ 用户请求访问应用程序。 应用程序确定用户尚未通过身份验证，然后将用户重定向到身份服务器。 用户向身份服务器进行身份验证。 身份服务器在成功身份验证后向用户发送访问令牌/ ID令牌。 该令牌由加密密钥签名。 用户可以在应用程序中使用此令牌进行身份验证。 应用程序通过检查公共加密密钥来检查签名密钥是否由身份服务器签名，从而验证签名密钥。 在这种情况下，用户已成功通过身份验证！

For the token, JSON Web Token (JWT) is used. A JWT consists of a header, payload, and signature. The header contains the algorithm used to sign the token. A payload is essentially a JSON object where additional properties about the user can be added. Since the token is signed by the identity server, the information can be trusted by the consuming application. The application can validate the token against the public key of the certificate used by the identity server for signing the token.

对于令牌，使用JSON Web令牌(JWT) 。 JWT由标头，有效负载和签名组成。 标头包含用于对令牌进行签名的算法。 有效负载本质上是一个JSON对象，可以在其中添加有关用户的其他属性。 由于令牌是由身份服务器签名的，因此消费应用程序可以信任该信息。 应用程序可以根据身份服务器用于签署令牌的证书的公钥来验证令牌。

High-level flow between user, application and identity server

用户，应用程序和身份服务器之间的高级流程

什么是OAuth2？(What is OAuth2?)

During the explanation of OpenID Connect, the term OAuth2 already fell. OAuth2 is an industry-standard authorization protocol. It offers specific authorization flows (described as grants inside the specification) for web applications, desktop applications, mobile phones and living room devices.

在解释OpenID Connect时，术语OAuth2已经掉了。 OAuth2是行业标准的授权协议。 它为Web应用程序，台式机应用程序，移动电话和客厅设备提供了特定的授权流程(在规范内称为授予)。

The flow described in the OpenID Connect explanation makes actually use of one of the supported grant types, the Authorization Code grant type to be exact.

OpenID Connect解释中描述的流程实际上使用了一种受支持的授权类型，确切地说是授权码授权类型。

With this flow, the user is redirected to the Identity Server where authentication and authorization are handled. The client (the application that requests the user information) gets authorization by the user to the needed information. This is done by configuring the right scopes. Scopes resemble the type of data that a specific client has access to. Examples of scopes are email and address, which resemble respectively the user’s email address and address.

通过此流程，将用户重定向到身份服务器，在该服务器上处理身份验证和授权。 客户端(请求用户信息的应用程序)获得用户对所需信息的授权。 这是通过配置正确的作用域来完成的。 范围类似于特定客户端可以访问的数据类型。 范围的示例是电子邮件和地址，分别类似于用户的电子邮件地址和地址。

The scopes are requested by the application during the authentication process. When the user authenticates himself on the identity server, the user as well gets the possibility to give the application authorization for the requested data. When given authorization, the data will be added to the payload of the token and passed to the application.

范围是由应用程序在身份验证过程中请求的。 当用户在身份服务器上对自己进行身份验证时，用户也有可能为请求的数据授予应用程序授权。 获得授权后，数据将被添加到令牌的有效载荷中并传递给应用程序。

In the identity server, there is the possibility to persist the roles that are connected to the user. An identity server could be set up for all employees in a company. These employees have different roles depending on their role in the company. The identity server could share the assigned roles to a specific user in the token. In this way, this can be shared with consuming applications.

在身份服务器中，可以保留与用户连接的角色。 可以为公司中的所有员工设置身份服务器。 这些员工根据他们在公司中的角色具有不同的角色。 身份服务器可以将分配的角色共享给令牌中的特定用户。 这样，可以与使用中的应用程序共享。

特定于应用程序的授权逻辑应内置在哪里？ (Where should application-specific authorization logic be built in?)

The choice to build authentication in a separate centralized responsible service has been advocated in the previous section. This becomes harder for application-specific authorization logic. In a microservice architecture, the services itself should not be exposed directly to the consuming application. Managing connections to all your microservices becomes unmanageable.

上一节已经提倡选择在单独的集中负责的服务中构建身份验证。 对于特定于应用程序的授权逻辑，这变得更加困难。 在微服务架构中，服务本身不应直接暴露给使用中的应用程序。 管理与所有微服务的连接变得难以管理。

Implementing an API gateway creates a single entry point for consumers to communicate with. The API gateway routes the requests to the upstream microservices.

实施API网关会创建一个供消费者与之通信的单一入口点。 API网关将请求路由到上游微服务。

API gateway in relation to other components

与其他组件有关的API网关

When multiple consumers are in play, creating specific API gateways could be a solution to create separate specific endpoints for each consumer. This variation is called the Backends for Frontends pattern. This way only the endpoints are specifically implemented for each consumer. The drawback of this is that it adds another separate service per consumer that needs to be maintained.

当有多个使用者使用时，创建特定的API网关可能是为每个使用者创建单独的特定端点的解决方案。 这种变化称为“前端的后端”模式。 这样，仅为每个使用者专门实现端点。 这样做的缺点是，它为每个使用者增加了另一个需要维护的单独服务。

在网关中处理特定于应用程序的授权 (Handling application-specific authorization in the gateway)

One solution to handle application-specific authorization is by implementing this in the API gateway. Restricting requests to specific endpoints become in this way possible. The drawback of implementing authorization in the API gateway is that it can be only role-based access to endpoints. Implementing additional checks on access to specific domain objects would need to create specific domain logic inside the API gateway and therefore will create leakage of domain logic. Furthermore when introducing multiple backends for frontends/API gateways, managing the authorization becomes harder and harder.

处理特定于应用程序的授权的一种解决方案是在API网关中实现此功能。 以这种方式将请求限制到特定端点成为可能。 在API网关中实现授权的缺点在于，它只能是基于角色的端点访问。 实施对特定域对象的访问的附加检查将需要在API网关内部创建特定域逻辑，因此将导致域逻辑泄漏。 此外，在为前端/ API网关引入多个后端时，管理授权变得越来越困难。

在微服务中处理特定于应用程序的授权 (Handling application-specific authorization in the microservices)

A better solution would be to make the microservices responsible for handling authorization. The API gateway should pass the JWT along with the request towards the microservice. As explained before, the JWT will contain the roles assigned to the user. Since the API gateway is still responsible for authentication, validating the token has already been done when the microservice receives the request. With the assigned roles to the user executing the request, the microservice can now determine whether the user is authorized for the desired request. In this way, the application-specific only needs to be implemented in one place. A drawback of this is that authorization will be more scattered around in multiple services. When having a lot of roles that change very often, this becomes more tedious to manage.

更好的解决方案是使微服务负责处理授权。 API网关应将JWT与请求一起传递给微服务。 如前所述，JWT将包含分配给用户的角色。 由于API网关仍负责身份验证，因此在微服务​​收到请求时，已经完成了令牌的验证。 通过为执行请求的用户分配角色，微服务现在可以确定用户是否已获得所需请求的授权。 这样，只需要在一个地方实现特定于应用程序。 这样做的一个缺点是授权将分散在多个服务中。 当许多角色经常变化时，管理起来就变得很乏味。

结论 (Conclusion)

When implementing authentication and authorization into microservices, the process becomes much more complex than in a traditional monolithic architecture.

当在微服务中实现身份验证和授权时，该过程比传统的单片架构要复杂得多。

While authentication and authorization are both terms used in the spectrum of securing an application, they don’t cover the same thing. Authentication is about verifying the identity of an entity it claims to be. Authorization is the process about determining whether the entity is allowed to do a specific action or access specific data.

虽然身份验证和授权都是保护应用程序安全的术语，但它们涵盖的范围并不相同。 身份验证是关于验证其声称为实体的身份。 授权是有关确定是否允许实体执行特定操作或访问特定数据的过程。

Authentication and authorization to applications inside a microservice architecture are usually implemented in a centralized service that is responsible for this. There are several solutions for this, like WSO2 Identity Server (Java), IdentityServer4 (.NET) and OAuth2orize (Node.js). These services support OAuth2 and OpenID Connect, which are underlying, industry-standard protocols for authorization and authentication.

对微服务架构内的应用程序的身份验证和授权通常是在对此负责的集中式服务中实现的。 有多种解决方案，例如WSO2身份服务器(Java)，IdentityServer4(.NET)和OAuth2orize(Node.js)。 这些服务支持OAuth2和OpenID Connect，它们是用于授权和身份验证的基础，行业标准协议。

Implementing authentication checks should terminate inside the API gateway. Implementing authorization can be done either in the API gateway or in the microservices. To be able to do extensive application-specific authorization checks, authorization should be handled in the specific microservices. This can be done by passing along the JWT with the request. In this way, application-specific authorization for domain objects won’t be leaked to the API gateway.

实施身份验证检查应在API网关内部终止。 可以在API网关或微服务中实现授权。 为了能够进行广泛的特定于应用程序的授权检查，应该在特定的微服务中处理授权。 这可以通过将JWT与请求一起传递来完成。 这样，域对象的特定于应用程序的授权就不会泄漏到API网关。

翻译自: https://medium.com/swlh/authentication-and-authorization-in-microservices-how-to-implement-it-5d01ed683d6f

shiro实现身份验证