Learning_xzj的博客

Spring Boot是作为Spring框架的应用开发的一个进化阶段出现的。与其说你需要编写所有的配置，不如说Spring Boot已经预设了一些配置，所以你可以只覆盖那些与你的实现不匹配的配置。我们也称这种方法为 “惯例–配置”。在这种开发应用程序的方式存在之前，开发人员为他们必须创建的所有应用程序反复编写几十行代码。在过去，当我们以单体方式开发大多数架构时，这种情况不太明显。在单体架构下，你只需要在开始时写一次这些配置，之后就很少需要再碰它们。当面向服务的软件架构发展起来后，我们开始感受到为配置每个服务

在本节中，你将学习如何实现UserDetails接口来描述你的应用程序中的用户。我们将讨论UserDetails合约所声明的方法，以了解我们如何以及为什么要实现每一个方法。首先，让我们看看下面列表中介绍的接口。清单3.1 UserDetails 接口getUsername()和getPassword()方法返回，正如你所期望的，用户名和密码。应用程序在认证过程中使用这些值，这些是该合同中唯一与认证有关的细节。其他五个方法都与授权用户访问应用程序的资源有关。

在本节中，我们将讨论PasswordEncoder合约的定义。你实现了这个契约，告诉Spring Security如何验证用户的密码。在验证过程中，PasswordEncoder决定一个密码是否有效。每个系统都会以某种方式存储密码编码。你最好是将它们散列存储，这样就不会有机会被人读取密码。密码编码器也可以对密码进行编码。合同中声明的方法encode()和matches()，实际上是对其责任的定义。这两个都是同一个契约的一部分，因为这些都是强关联的，一个接一个。

在这一节中，我们将讨论实现自定义认证逻辑。我们分析了与此责任相关的Spring Security合同，以了解其定义。有了这些细节，你就可以通过第5.1.3节中的一个代码例子来实现自定义认证逻辑。Spring Security中的AuthenticationProvider负责处理认证逻辑。AuthenticationProvider接口的默认实现将寻找系统用户的责任交给了UserDetailsService。在认证过程中，它也使用PasswordEncoder进行密码管理。

在完成了用户和密码管理后，我们可以开始编写自定义认证逻辑。要做到这一点，我们必须实现一个AuthenticationProvider（列表6.12），并在Spring Security认证架构中注册它。编写认证逻辑所需的依赖性是UserDetailsService的实现和两个密码编码器。除了自动连接这些，我们还覆盖了authenticate()和supports()方法。我们实现supports()方法来指定支持的认证实现类型是UsernamePasswordAuthenticationToken。

在本章中，我们将讨论授权。授权是一个过程，在这个过程中，系统决定一个被识别的客户是否具有访问所请求资源的权限。

在开发中，我们不太可能对所有请求应用相同的规则。例如某些api，只有一些特定的用户可以调用，而其他api可能是所有人都可以访问的。每个应用程序，根据业务需求，都有自己的自定义授权配置。让我们来讨论一下，当我们写访问配置时，你有哪些选项可以参考不同的请求。

在Spring Security中，HTTP filters（过滤器）对不同的HTTP请求进行过滤。在第三章到第五章，我们讨论了HTTP的认证和授权架构，我经常提到过滤器。在Spring Security中，一般来说，HTTP filters对请求进行过滤。这些过滤器形成了一个责任链。一个过滤器接收一个请求，执行其逻辑，并最终将请求委托给链中的下一个过滤器（图9.1）。图9.1 过滤器链接收请求。每个过滤器使用一个管理器来对请求应用特定的逻辑，并最终将请求沿着链子进一步委托给下一个过滤器。这个想法很简单。当

我们已经了解了过滤器链以及它在Spring Security架构中的作用。我们在第9章中研究了几个例子，在这些例子中我们定制了过滤器链。但Spring Security也会在链上添加自己的过滤器。在本章中，我们将讨论应用CSRF保护的过滤器和与CORS配置相关的过滤器。你将学习如何定制这些过滤器，使之完美地适合你的应用场景。你可能已经注意到，到目前为止的大多数例子中，我们只用HTTP GET实现了我们的api。此外，当我们需要配置HTTP POST时，我们还必须在配置中添加一个补充指令来禁用CSRF保护。之

现在又到了将你所学到的东西付诸行动的时候了，这个练习向你展示了整个画面。系好你的安全带，打开你的IDE，准备好迎接一场冒险吧!在本章中，我们将设计一个由三个角色组成的系统：客户端、认证端和业务逻辑端。从这三个角色中，我们将实现认证端的后端部分和一个业务逻辑端。正如你所看到的，我们的例子更加复杂，表明我们越来越接近真实世界的场景了。这个练习也是一个很好的机会来回顾、应用和更好地理解你已经学过的东西，并触及新的主题，如JSON Web Tokens（JWT）。你还可以看到在一个系统中分离认证和授权责任的演示。在

如果你已经在使用OAuth 2，我知道你在想什么：OAuth 2框架是一个庞大的主题，在四章中，你会学到所有你需要知道的关于用Spring Security应用OAuth 2的知识。在这一章中，我们将从概述开始，你会发现OAuth 2框架的主要角色是用户、客户端、资源服务器和授权服务器。在总体介绍之后，你将学习如何使用Spring Security来实现客户端。然后，在第13章到第15章，我们将讨论实现最后两个组件：资源服务器和授权服务器。为了达到这个目标，在本章中，我们将讨论什么是OAuth 2，然后我们

在本节中，我们将讨论用户管理。authorization server是处理OAuth 2框架中的用户认证的组件。因此，它自然需要管理用户。幸运的是，用户管理的实现与你在第3章和第4章中学到的并没有改变。我们继续使用UserDetails、UserDetailsService和UserDetailsManager接口来管理凭证。而为了管理密码，我们继续使用PasswordEncoder接口。在这里，这些接口具有相同的角色，并且与你在第3章和第4章中学到的相同。

在本章中，我们将讨论用Spring Security实现一个资源服务器。 资源服务器是管理用户资源的组件。资源服务器这个名字一开始可能并不引人注意，但就OAuth 2而言，它代表了你所保护的后端，就像我们在前几章所保护的其他应用一样。例如，还记得我们在第11章实现的业务逻辑服务器吗？为了允许客户端访问资源，资源服务器需要一个有效的访问令牌。客户端从授权服务器获得一个访问令牌，并通过在HTTP请求头中添加令牌来调用资源服务器上的资源。图14.1提供了第12章的复习内容，显示了资源服务器在OAuth 2认证架构

在这一章中，我们将讨论使用JSON Web令牌（JWTs）来实现令牌。你在第14章中了解到，资源服务器需要验证由授权服务器发出的令牌。我告诉了你三种方法来做到这一点：使用加密签名来验证令牌的好处是允许资源服务器验证令牌，而不需要直接调用授权服务器，也不需要共享数据库。这种实现令牌验证的方法常用于用OAuth 2实现认证和授权的系统中。由于这个原因，你需要知道这种实现令牌验证的方法。我们将为这个方法写一个例子，就像我们在第14章为其他两个方法写的那样。签署令牌最直接的方法是使用对称密钥。使用这种方法，使用同一

到现在为止，我们讨论了配置认证的各种方法。我们在第2章中从最直接的方法–HTTP Basic开始，然后我在第5章中向你展示了如何设置表单登录。我们在第12章到第15章中讨论了OAuth 2。但在授权方面，我们只讨论了api层面的配置。假设你的应用不是Web应用–你不能也使用Spring Security进行认证和授权吗？Spring Security很适合那些不通过HTTP api使用你的应用程序的场景。在本章中，你将学习如何在方法层面配置授权。我们将使用这种方法来配置Web和非Web应用程序中的授权，我们

在第16章中，你学会了如何使用全局方法安全来应用授权规则。我们研究了使用@PreAuthorize和@PostAuthorize注解的例子。通过使用这些注解，你可以应用一种方法，即应用程序要么允许方法调用，要么完全拒绝调用。 假设你不想禁止调用一个方法，但你想确保发送给它的参数遵循一些规则。或者，在另一种情况下，你想确保有人调用该方法后，该方法的调用者只收到返回值的授权部分。我们将这样的功能命名为过滤，并将其分为两类。图17.1 客户端调用api，提供一个不符合授权规则的值。在预授权的情况下，该方法根本就没

在18.2.3节中，我们设法获得了一个访问令牌。我们还添加了一个客户端注册，并配置了用户来获取令牌。但是，令牌仍然没有提供我们的资源服务器在应用授权规则时需要的所有细节。为了给我们的方案写一个完整的应用程序，我们需要为我们的用户添加角色。为一个用户添加角色很简单。左侧菜单中的 "角色 "选项卡允许你找到所有角色的列表并添加新的角色，如图18.19所示。我创建了两个新角色：fitnessuser和fitnessadmin。