## GeoServer Security
> GeoServer中的Security子系统是基于Spring Security的。这里介绍的是通过GeoServer的Web管理界面来如何配置Security。
### 1. Security 设置
### 密码
> 密码是任何安全系统的核心部分。
`GeoServer`配置存储两种类型的密码:
- 访问`GeoServer`资源的用户帐号密码；
- 内部用于访问外部服务(如数据库`postgis`和关联`OGC`服务)的密码。
由于这些密码通常存储在磁盘上，因此强烈建议对它们进行加密，而不是存储为可读的明文文本。`GeoServer`安全提供了四种密码加密方案：
1. **空密码**：该方案是不可逆转的。任何密码都被编码为空字符串，因此无法重新计算纯文本密码。该方案用于用户/组服务，并结合使用后端系统的身份验证机制。例如，针对`LDAP`服务器或`JDBC`数据库的用户名/密码身份验证。在这些场景中，将密码本地存储到`GeoServer`是没有意义的。
2. **明文密码**：纯文本密码根本不提供加密。在这种情况下，任何可以访问文件系统的人都可以读取密码。由于显而易见的原因，除了最基本的测试服务器之外，不建议使用这种方法。
3. **摘要密码(可加盐)**：摘要加密是不可逆转的。它通过迭代过程对密码应用`SHA-256`加密散列函数10万次。该方案是“单向的”，因为实际上不可能从其散列表示中反转和获取原始密码。为了防止已知的攻击，在生成密钥时将一个称为salt的随机值添加到密码中。对于每次消化，使用一种单独的随机盐。对相同密码进行两次摘要处理会得到不同的散列表示。
4. **`PBE`密码**：[Password-based encryption](http://www.javamex.com/tutorials/cryptography/password_based_encryption.shtml)基于密码的加密(`PBE`)通常使用用户提供的密码来生成加密密钥。这个方案是可逆的。
密码加密方案是全局设置的，会影响外部资源密码加密的，同时也指定为每个`user/group`服务的加密方案。
外部资源的加密方案必须是可逆的，而用户/组服务可以使用任何方案。
#### Password-based encryption
`GeoServer`支持两种`PBE`：
- `Weak PBE`：弱`PBE` (`GeoServer`默认值)使用一种相对容易破解的基本加密方法。加密密钥使用`MD5`迭代1000次从密码中获得。加密算法本身是DES (Data encryption Standard)。DES的有效密钥长度为56位，这对于当今的计算机系统来说并不是一个真正的挑战。
- `Strong PBE`：`强PBE`使用更强大的加密方法，基于`AES 256`位算法和`CBC`。密钥长度为256位，使用`SHA-256`而不是`MD5`导出。强烈建议使用`Strong PBE`。
以“`geoserver`”密码加密为“`crypt1:KWhO7jrTz/Gi0oTQRKsVeCmWIZY5VZaD`”为例：
> 密文和盐是64进制编码的。
- `crypt1`表示`弱PBE`的使用情况。
- `强PBE`的前缀是`crypt2`。
#### 可逆加密
密码加密方法可以是可逆的，这意味着有可能(也是可取的)从其加密版本获得明文密码。可逆密码对于数据库连接或外部`OGC`服务(如级联`WMS`和级联`WFS`)是必需的，因为`GeoServer`必须能够解码加密的密码并将其传递给外部服务。明文密码和`PBE`密码是可逆的。
不可逆转的密码提供了最高级别的安全性，因此应该用于用户帐户和其他任何可能的地方。强烈建议使用密码摘要，不需要安装不受限制的策略文件。
#### 密钥和密钥库
要使可逆密码提供有意义的安全级别，必须以某种方式限制对密码的访问。
在`GeoServer`中，密码的加密和解密涉及到秘密共享和密钥生成，这些密钥存储在典型的Java密钥库中。`GeoServer`使用自己的密钥存储库，名为`GeoServer.jceks`，它位于`GeoServer`数据目录下的security目录中。该文件以`JCEKS`格式存储，而不是默认的`JKS`格式。`JKS`不支持存储共享密钥。
还可以为`GeoServer`设置密钥存储库密码。这个密码有两个用途:
- 保护对密钥存储库的访问
- 保护对`GeoServer Root`帐户的访问权限
默认情况下，使用纯文本生成`keystore`密码并将其存储在名为`security/masterpw.info`的文件中。
从现有的`GeoServer`数据目录(2.1版本及以下)，则该算法尝试找出角色为`ROLE_ADMINISTRATOR`的用户的密码。如果发现该密码，且密码长度至少为8个字符，则`GeoServer`使用该密码作为`keystore`密码。同样，所选用户的名称可以在`security/masterpw.info`中找到。
> `GeoServer`，读取该文件并验证密钥存储库密码。成功后，该文件将被删除。
>
> 如果删除security文件夹，用户的密码和`postgis`的密码都会被删除，所以谨慎处理。
设置一个Active keystore password provider：
1. 
2. 
3. Changing the keystore password，密码策略要求最少要8个字符
4. 
5. 更改完成后，摘要密码`masterpw.digest`会更新，同时`security/masterpw/default/passwd`也会更新。
默认情况下，禁用使用“`Keystore Password`”登录`Admin GUI`和`REST api`。为了启用它，您需要手动更改密钥库密码提供程序`config.xml`，通常位于`security/masterpw/default/config.xml`中，通过添加以下语句:
```xml
true
```
#### 密码策略
密码策略定义了对密码的约束，如密码长度、大小写和所需的字符类组合。密码策略在添加用户/组业务时指定，用于创建新用户和修改现有用户密码时对密码进行约束。
#### 参数化的密码
### 角色系统
GeoServer中的安全性是基于**角色**的系统，其中创建了用于服务特定功能的角色。具有特定功能的角色的示例包括访问Web Feature Service (WFS)、管理Web管理接口和读取特定层的角色。
角色分配给用户和用户组，并确定允许这些用户或组执行哪些操作。
通过认证方式对用户进行授权。
#### 用户与组
GeoServer用户的定义与大多数安全系统类似。虽然正确的Java术语是**principal**主体(主体是指人、计算机、软件系统等)，但在整个GeoServer文档中都采用了用户一词。为每个用户维护以下信息:
- 用户名
- 密码
- 指示用户是否启用的标志(这是默认值)。禁用的用户被禁止登录。现有用户会话不受影响。
- 键/值对的集合
键/值对是特定于实现的，可以由用户或组所属的用户/组服务配置。例如，维护用户信息(如姓名、电子邮件地址等)的用户/组服务可能希望将这些属性与用户对象关联起来
一个GeoServer组 **group** 就是一组用户。对于每一组，保持以下信息:
- Group name
- 指示组是否启用的标志(这是默认值)。禁用的组不参与该组中包含的所有用户的角色计算。
- 属于该组的用户列表
#### 用户/组服务
用户/组服务为用户/组提供以下信息:
- 用户列表
- 组列表，包括与每个组关联的用户
- 用户密码
许多身份验证提供者将使用用户/组服务来执行身份验证。在这种情况下，用户/组服务将是对用户和密码进行身份验证的数据库。根据[Authentication chain](https://docs.geoserver.org/latest/en/user/security/auth/chain.html#security-auth-chain) 身份验证链的配置方式，在任何给定时间可能有零个、一个或多个活跃的用户/组服务。
用户/组服务可能是只读的，提供对用户信息的访问，但不允许添加或修改新的用户和组。如果将用户/组服务配置为将用户和组数据库委托给外部服务，则可能发生这种情况。外部LDAP服务器就是一个例子。
默认情况下，GeoServer支持三种类型的用户/组服务:
- [XML](https://docs.geoserver.org/latest/en/user/security/usergrouprole/usergroupservices.html#security-rolesystem-usergroupxml)—*(Default)* User/group service persisted as XML
- User/group service persisted in database via JDBC
- [LDAP](https://docs.geoserver.org/latest/en/user/security/usergrouprole/usergroupservices.html#security-rolesystem-usergroupldap)—User/group service obtained from an LDAP repository
还可以向GeoServer添加其他服务，例如 [AuthKey](https://docs.geoserver.org/latest/en/user/extensions/authkey/index.html#authkey) 扩展提供的服务。
**XML user/group service**
XML用户/组服务将用户/组数据库保存在XML文件中。这是GeoServer的默认行为。
该服务将用户数据库表示为XML，并与此XML schema模式相对应。
> XML用户/组文件users.xml位于GeoServer数据目录security/usergroup//users.xml中，其中是用户/组服务的名称。
以下是默认GeoServer配置附带的users.xml的内容:
```xml
```
**JDBC user/group service**
JDBC user/group service 通过JDBC调用数据库，持久化用户/组数据，管理多个表中的用户信息。用户/组数据库模式如下:
用户表：`users`
| Field | Type | Null | Key |
| :------- | :----------- | :--- | :--- |
| name | varchar(128) | NO | PRI |
| password | varchar(254) | YES | |
| enabled | char(1) | NO | |
用户属性表：`user_props`
| Field | Type | Null | Key |
| :-------- | :------------ | :--- | :--- |
| username | varchar(128) | NO | PRI |
| propname | varchar(64) | NO | PRI |
| propvalue | varchar(2048) | YES | |
用户组信息表：`groups`
| Field | Type | Null | Key |
| :------ | :----------- | :--- | :--- |
| name | varchar(128) | NO | PRI |
| enabled | char(1) | NO | |
用户组成员表：`group_members`
| Field | Type | Null | Key |
| :-------- | :----------- | :--- | :--- |
| groupname | varchar(128) | NO | PRI |
| username | varchar(128) | NO | PRI |
`users`表是主表，包含带有关联密码的用户列表;
`user_props`表将附加属性映射到用户;
`groups`表列出了所有可用的组;
`group_members`表映射了哪些用户属于哪些组。
> 默认的GeoServer安全配置中上述四张表都是空的
**LDAP user/group service**
LDAP用户/组服务是一个**只读**用户/组服务，它将用户和组从LDAP存储库映射到GeoServer用户和组。
用户从特定的LDAP节点中提取，配置为Users搜索库。组是从特定的LDAP节点中提取的，并配置为Groups搜索基。每个匹配的用户对应一个用户映射，每个匹配的组对应一个组映射。
> LDAP（Light Directory Access Portocol），它是基于X.500标准的轻量级目录访问协议。目录是一个为查询、浏览和搜索而优化的数据库，它成树状结构组织数据，类似文件目录一样。
>
> LDAP目录服务是由目录数据库和一套访问协议组成的系统。
可以指定包含组名(如cn)、用户名(如uid)以及两者之间的成员关系(如member)的属性。但是，也可以指定特定的过滤器来搜索所有用户/组(例如cn=*)，按名称查找用户/组(例如cn={0})并将用户映射到组(例如member={0})。这些过滤器也可以从属性名中自动派生出来。另外，如果提供了过滤器，属性名也可以保留为空。
对于用户，可以通过提供一个逗号分隔的属性名列表，从LDAP服务器填充其他属性(键/值对，请参阅users和Groups)。
检索用户/组信息可以匿名完成，如果LDAP存储库需要，也可以使用给定的用户名/密码。
此类型角色服务的配置文件(config.xml)示例如下:
```xml
52857278:13c7ffd66a8:-7ffd
default
org.geoserver.security.xml.XMLUserGroupService
users.xml
10000
true
digestPasswordEncoder
default
```
#### 角色
GeoServer角色是与执行某些任务或访问特定资源相关联的关键。角色被分配给用户`users`和组`groups`，授权他们执行与角色相关的操作。一个GeoServer角色包括以下内容:
- 角色名
- 父角色
- 设置键值对
GeoServer角色支持继承—子角色继承授予父角色的所有访问权限。
键/值对是特定于实现的，可以由用户或组所属的角色服务配置。例如，基于员工组织分配角色的角色服务可能希望将其他信息(如Department Name)与角色关联。
GeoServer有许多系统角色，这些角色的名称是保留的。不允许添加具有保留名称的新GeoServer角色。
- `ROLE_ADMINISTRATOR`：提供对所有操作和资源的访问
- `ROLE_GROUP_ADMIN`：管理用户组的特殊角色
- `ROLE_AUTHENTICATED`：分配给每个身份验证成功的用户
- `ROLE_ANONYMOUS`：启用匿名身份验证且用户未登录时分配
#### 角色服务
角色服务为角色提供如下信息:
- 角色列表
- 计算给定用户的角色分配
- 角色到系统角色ROLE_ADMINISTRATOR的映射
- 角色到系统角色ROLE_GROUP_ADMIN的映射
当用户/组服务加载有关用户或组的信息时，它将委托给角色服务来确定应该将哪些角色分配给用户或组。
与用户/组服务不同，**在任何给定时间只有一个角色服务是活动的**。在“设置”页面中设置默认角色服务。
默认情况下，GeoServer支持两种类型的角色服务:
- XML——(默认)角色服务作为XML持久化
- JDBC——角色服务通过JDBC持久化在数据库中
**将角色映射到系统角色**
若要将系统角色`ROLE_ADMINISTRATOR`分配给用户或组，则需要创建不同名称的新角色，并将其映射给角色`ROLE_ADMINISTRATOR`。对于系统角色`ROLE_GROUP_ADMIN`也是如此。映射存储在服务的config.xml文件中。
```xml
52857278:13c7ffd66a8:-7ffc
default
org.geoserver.security.xml.XMLRoleService
roles.xml
10000
true
ADMIN
GROUP_ADMIN
```
在本例中，赋予角色ADMIN的用户或组同时赋予系统角色ROLE_ADMINISTRATOR。对于GROUP_ADMIN和ROLE_GROUP_ADMIN也是如此。
**XML角色服务**
XML角色服务将角色数据库保存在XML文件中（这是GeoServer的默认角色服务）。该服务将用户数据库表示为XML，并与此XML模式相对应。
> XML角色文件roles.xml位于GeoServer数据目录security/role//roles.xml中，其中是角色服务的名称。
配置本地角色“ADMIN”映射到系统角色“ROLE_ADMINISTRATOR”。另外，GROUP_ADMIN映射到ROLE_GROUP_ADMIN。映射存储在每个角色服务的config.xml文件中。
```xml
```
该配置包含ADMIN和GROUP_ADMIN两个角色。角色ADMIN被分配给ADMIN用户。由于ADMIN角色已经映射给系统角色ROLE_ADMINISTRATOR，所以在角色计算中，ADMIN用户被同时赋予了两个角色
示例：
**JDBC角色服务**
JDBC角色服务通过JDBC持久化角色数据库，管理多个表中的角色信息。角色数据库模式如下所示
角色表：roles
| Field | Type | Null | Key |
| :----- | :---------- | :--- | :--- |
| name | varchar(64) | NO | PRI |
| parent | varchar(64) | YES | |
角色属性表：role_props
| Field | Type | Null | Key |
| :-------- | :------------ | :--- | :--- |
| rolename | varchar(64) | NO | PRI |
| propname | varchar(64) | NO | PRI |
| propvalue | varchar(2048) | YES | |
用户角色关联表：user_roles
| Field | Type | Null | Key |
| :------- | :----------- | :--- | :--- |
| username | varchar(128) | NO | PRI |
| rolename | varchar(64) | NO | PRI |
用户组与角色关联表：group_roles
| Field | Type | Null | Key |
| :-------- | :----------- | :--- | :--- |
| groupname | varchar(128) | NO | PRI |
| rolename | varchar(64) | NO | PRI |
- roles表是主表，包含角色列表。GeoServer中的角色支持继承，所以一个角色可以有一个到父角色的链接。
- role_props表将其他属性映射到角色。
- user_roles表将用户映射到分配给他们的角色。
- group_roles表映射了哪些组被分配了哪些角色。
GeoServer中上述四张表都为空。
添加角色：
使用：在安全设置中选择刚刚新建的角色服务：
在去`用户/组`中添加用户：
**REST role service**
REST角色服务是一个**只读**角色服务，它将组和关联用户映射到远程REST web服务中的角色.
REST服务必须支持JSON编码。
下面是REST角色服务(基于LDAP角色服务，它同样必须使网络调用工作)提供的重要方法的列表:
| Method | Mandatory |
| :------------------------------ | :----------------------------------------------------------- |
| *getUserNamesForRole(roleName)* | N (implemented in LDAP, but I don’t see actual users of this method besides a utility method that nobody uses) |
| *getRolesForUser(user)* | Y |
| *getRolesForGroup(group)* | N |
| *getRoles()* | Y (used by the UI) |
| *getParentRole(role)* | N |
| *getAdminRole()* | Y |
| *getGroupAdminRole()* | Y |
| *getRoleCount()* | Y (does not seem to be used much, we can trivially implement it from getRoles() |
#### 角色服务与用户/组
**计算用户角色**
下图说明了用户/组服务和角色服务如何交互以计算用户角色。
在从用户/组服务中获取启用的用户时，必须标识分配给该用户的角色。鉴定程序为:
1. 获取该用户`user`的所有已启用组。如果一个组被禁用，它将被丢弃。
2. 获取与该用户关联的所有角色`role`，并将角色添加到结果集中。
3. 对于用户所属的每个已启用组，获取与该组关联的所有角色，并将角色添加到结果集中。
4. 对于结果集中的每个角色，获取所有祖先角色并将这些角色添加到结果集中。
5. 根据需要个性化结果集中的每个角色。
6. 如果结果集中存在本地admin角色，则添加角色ROLE_ADMINISTRATOR。
7. 如果结果集中存在本地组admin角色，则添加角色ROLE_GROUP_ADMIN。
**用户凭证的身份验证**
用户/组服务主要用于身份验证。身份验证链[Authentication chain](https://docs.geoserver.org/latest/en/user/security/auth/chain.html#security-auth-chain)中的身份验证提供者可以使用`user/group service`对用户凭证进行身份验证。
**GeoServer默认的安全配置**
### 认证
#### [Authentication chain](https://docs.geoserver.org/latest/en/user/security/auth/chain.html)
在身份验证中涉及三组GeoServer资源:
- web 管理界面
- OWS服务的认证
- REST接口服务的认证
了解身份验证链有助于解释GeoServer身份验证是如何工作的。身份验证链处理请求并应用某些身份验证机制。认证机制的例子包括:
- **Username/password**：通过在外部用户数据库中查找用户信息来执行身份验证
- **Browser cookie**：通过识别先前发送的浏览器cookie(也称为“Remember Me”)执行身份验证
- **LDAP**：对LDAP数据库执行身份验证
- **Anonymous**：本质上不执行身份验证，允许请求在没有任何凭据的情况下继续进行
在给定时间，GeoServer中可能有多个身份验证机制处于活动状态。下图说明了通用请求的流程。
在将请求分派给适当的服务或处理程序之前，GeoServer首先通过身份验证链过滤请求。请求按顺序传递给链中的每个机制，每个机制都有机会对请求进行身份验证。如果链中的一个机制能够成功地进行身份验证，则请求转到正常处理。否则，不会进一步路由请求，并向用户返回一个授权错误(通常是HTTP 401)。
**过滤链和执行链**
在GeoServer中，身份验证链实际上由两条链组成：
1. `filter chain`：它们决定是否需要对请求进行进一步的身份验证；
2. `provide chain`：它执行实际的身份验证。
过滤器链`filter chain`执行各种任务，包括:
- 从请求中收集用户凭据 credentials ，例如从基本和摘要身份验证头中；
- 处理事件，如结束会话(注销)，或设置“记住我”浏览器cookie；
- 执行会话集成，检测现有会话并在必要时创建新会话；
- 调用身份验证提供程序链来执行实际的身份验证。
过滤器链实际上被处理两次，分别在处理请求之前和之后。
执行链只关心执行请求的底层身份验证。当过滤器确定需要身份验证时，它由过滤器链调用。
**请求类型&筛选链**
> 不同的过滤器链可以应用于GeoServer中的每种不同类型的请求。
这是因为管理员可以配置不同过滤器链的列表，并为每个过滤器链配置匹配规则。只有配置的有序列表的第一个匹配链将应用于任何给定的请求。
匹配规则可以应用于:
- HTTP Method (GET, POST, etc.)
- 请求的路径部分的一个或多个ANT模式(例如/wms/**);如果指定了多个模式(以逗号分隔)，则其中任何一个都将匹配；
- 一个可选的正则表达式，用于匹配查询字符串上的一个或多个指定ANT模式的参数；如果路径匹配，也会检查查询字符串是否匹配；正则表达式可以在ANT模式之后使用管道(|)分隔符指定。
ANT模式支持以下通配符:
- `?`：匹配一个字符
- `*`：匹配零个或多个字符
- `**`：匹配路径中的零个或多个'目录'
查询字符串正则表达式将匹配完整的查询字符串(^和$终止符会自动追加)，因此要只匹配其中的一部分，请记住在表达式的前缀和后缀中加上**`.*`**(例如`.*request=getcapabilities.*`。
规则示例（ANT模式和查询字符串正则表达式）
| Pattern | Description |
| :-------------------------------------------------- | :----------------------------------------------------------- |
| `/wms, /wms/**` | simple ANT pattern |
| `/wms|.*request=GetMap.*` | ANT pattern and querystring regex to match one parameter |
| `/wms|(?=.*request=getmap)(?=.*format=image/png).*` | ANT pattern and querystring regex to match two parameters in any order |
| `/wms|(?=.*request=getmap)(?!.*format=image/png).*` | ANT pattern and querystring regex to match one parameters and be sure another one is not matched |
#### OWS和REST服务的认证
OWS和REST服务是**无状态**的，没有固有的“会话”意识，因此这些服务的身份验证方案要求客户端在**每个请求上提供凭据**。也就是说，支持“会话集成”，这意味着如果服务器上已经存在会话(来自并发认证的web管理会话)，它将用于身份验证。**此方案允许GeoServer避免OWS和REST服务创建会话的开销。**
默认GeoServer配置附带了对服务的HTTP基本身份验证的支持。
典型的认证过程如下:
1. 用户在不提供任何凭据的情况下发出服务请求
2. 如果用户正在访问不安全的资源，则正常处理请求
3. 如果用户正在访问受保护的资源:
- 将HTTP 401状态码发送回客户端，通常强制客户端提示输入凭据。
- 然后，在包含适当凭据的情况下重复服务请求，通常在HTTP报头中，就像在Basic Authentication中一样。
- 如果用户有足够的权限访问资源，请求将被正常处理，否则，将向客户端返回一个HTTP 404状态码。
4. 后续请求应包括原始用户凭据。
OWS服务的认证链如下所示:
在这个例子中，过滤器链由三个过滤器组成:
- **Session**：会话，执行会话集成，识别现有会话(但不创建新会话)
- **Basic Auth**： 从请求HTTP报头提取基本身份验证凭据
- **Anonymous**：处理匿名访问
提供者链由两个提供者组成:
- **Root**—Root帐户有一个特殊的“超级用户”提供者。由于很少使用此帐户，因此很少调用此提供程序。
- **Username/password**—对用户数据库进行用户名/密码认证
示例：
1. 匿名请求WMS服务的GetCapabilities
- 会话筛选器查找现有会话，但没有找到，因此继续处理。
- 基本认证筛选器在请求中查找基本授权标头，但由于请求是匿名的，因此筛选器没有找到。
- 最后，Anonymous过滤器以匿名方式执行并验证请求。
由于GetCapabilities是一个“发现”操作，因此它通常不会被锁定，即使在安全的服务器上也是如此。假设这里是这种情况，则匿名请求成功，并向客户端返回功能响应。不调用提供程序链。
2. 安全层的匿名WMS GetMap请求
此示例显示了当WMS客户端为安全层发出匿名GetMap请求时调用的过程。
该链的执行完全如上所述。
- 会话筛选器查找现有会话，但没有找到，因此继续处理。
- 基本认证筛选器在请求中查找基本授权标头，但由于请求是匿名的，因此筛选器没有找到。
- 最后，Anonymous过滤器以匿名方式执行并验证请求。
然而，在这种情况下，被访问的层是一个受保护的资源，因此GetMap请求的处理失败。服务器返回一个带有HTTP 401状态码的异常，这通常会触发客户端向用户呈现。
3. 带有用户提供凭据的WMS GetMap请求
此示例显示了WMS客户机从用户收集凭据并重新发出先前的安全层请求时调用的流程。
- 会话过滤器按照上面描述的方式执行，不执行任何操作。
- Basic Auth筛选器在请求中查找授权标头，提取其凭据，然后调用提供者链。
- 处理转移到执行实际身份验证的Username/password提供程序
如果凭据具有访问该层所需的特权，则请求的处理将正常继续，GetMap请求成功，返回映射响应。
如果凭据不够，则将提供HTTP 401状态码，这可能再次触发登录对话框0
#### 认证的提供者
在GeoServer中，有下列三种认证方式：
- 根据user/group服务的用户密码认证
- 根据LDAP服务的认证
- 根据JDBC连接数据库的认证
用户名和密码身份验证是默认的身份验证提供程序。
提供者简单地从传入请求(例如`Basic Authentication`请求)中获取用户名/密码，然后从用户/组服务加载用户信息并验证凭据。
JDBC身份验证提供者通过JDBC连接到数据库进行身份验证。
提供者从传入请求中获取用户名/密码，并尝试使用这些凭据创建数据库连接。提供者可以选择使用用户/组服务在成功的身份验证后加载用户信息。在此上下文中，用户/组服务将不用于密码验证，而仅用于角色分配。
### 服务安全
GeoServer支持提供service级别的访问控制，允许锁定服务的操作只有拥有被授权的角色的用户才能操作。在GeoServer中可以将服务大致分为两类：
- OWS 服务：例如WMS、WFS等
- REST 服务
OWS服务支持为特定服务或该服务中的特定操作全局设置安全访问约束。一些例子包括：
- 保护整个WFS服务，因此只有经过身份验证的用户才能访问所有WFS操作。
- 允许匿名访问只读WFS操作，如GetCapabilities，但保护写操作，如Transaction。
- 通过保护所有操作而不向任何用户应用适当的角色来禁用WFS服务。
OWS服务安全访问规则在名为services的文件中指定。属性，该属性位于GeoServer数据目录中的security目录中。该文件包含将服务操作映射到已定义角色的规则列表。指定规则的语法如下所示
### 1. Key authentication
### 2. CAS