meface/security.md at main

30 KiB

Raw Permalink Blame History

GeoServer Security

GeoServer中的Security子系统是基于Spring Security的。这里介绍的是通过GeoServer的Web管理界面来如何配置Security。

1. Security 设置

密码

密码是任何安全系统的核心部分。

GeoServer配置存储两种类型的密码:

访问GeoServer资源的用户帐号密码；
内部用于访问外部服务(如数据库postgis和关联OGC服务)的密码。

由于这些密码通常存储在磁盘上，因此强烈建议对它们进行加密，而不是存储为可读的明文文本。GeoServer安全提供了四种密码加密方案：

空密码：该方案是不可逆转的。任何密码都被编码为空字符串，因此无法重新计算纯文本密码。该方案用于用户/组服务，并结合使用后端系统的身份验证机制。例如，针对LDAP服务器或JDBC数据库的用户名/密码身份验证。在这些场景中，将密码本地存储到GeoServer是没有意义的。
明文密码：纯文本密码根本不提供加密。在这种情况下，任何可以访问文件系统的人都可以读取密码。由于显而易见的原因，除了最基本的测试服务器之外，不建议使用这种方法。
摘要密码(可加盐)：摘要加密是不可逆转的。它通过迭代过程对密码应用SHA-256加密散列函数10万次。该方案是“单向的”，因为实际上不可能从其散列表示中反转和获取原始密码。为了防止已知的攻击，在生成密钥时将一个称为salt的随机值添加到密码中。对于每次消化，使用一种单独的随机盐。对相同密码进行两次摘要处理会得到不同的散列表示。
PBE密码：Password-based encryption基于密码的加密(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：

Changing the keystore password，密码策略要求最少要8个字符
更改完成后，摘要密码masterpw.digest会更新，同时security/masterpw/default/passwd也会更新。

默认情况下，禁用使用“Keystore Password”登录Admin GUI和REST api。为了启用它，您需要手动更改密钥库密码提供程序config.xml，通常位于security/masterpw/default/config.xml中，通过添加以下语句:

<loginEnabled>true</loginEnabled>

密码策略

密码策略定义了对密码的约束，如密码长度、大小写和所需的字符类组合。密码策略在添加用户/组业务时指定，用于创建新用户和修改现有用户密码时对密码进行约束。

参数化的密码

角色系统

GeoServer中的安全性是基于角色的系统，其中创建了用于服务特定功能的角色。具有特定功能的角色的示例包括访问Web Feature Service (WFS)、管理Web管理接口和读取特定层的角色。

角色分配给用户和用户组，并确定允许这些用户或组执行哪些操作。

通过认证方式对用户进行授权。

用户与组

GeoServer用户的定义与大多数安全系统类似。虽然正确的Java术语是principal主体(主体是指人、计算机、软件系统等)，但在整个GeoServer文档中都采用了用户一词。为每个用户维护以下信息:

用户名
密码
指示用户是否启用的标志(这是默认值)。禁用的用户被禁止登录。现有用户会话不受影响。
键/值对的集合

键/值对是特定于实现的，可以由用户或组所属的用户/组服务配置。例如，维护用户信息(如姓名、电子邮件地址等)的用户/组服务可能希望将这些属性与用户对象关联起来

一个GeoServer组 group 就是一组用户。对于每一组，保持以下信息:

Group name
指示组是否启用的标志(这是默认值)。禁用的组不参与该组中包含的所有用户的角色计算。
属于该组的用户列表

用户/组服务

用户/组服务为用户/组提供以下信息:

用户列表
组列表，包括与每个组关联的用户
用户密码

许多身份验证提供者将使用用户/组服务来执行身份验证。在这种情况下，用户/组服务将是对用户和密码进行身份验证的数据库。根据Authentication chain 身份验证链的配置方式，在任何给定时间可能有零个、一个或多个活跃的用户/组服务。

用户/组服务可能是只读的，提供对用户信息的访问，但不允许添加或修改新的用户和组。如果将用户/组服务配置为将用户和组数据库委托给外部服务，则可能发生这种情况。外部LDAP服务器就是一个例子。

默认情况下，GeoServer支持三种类型的用户/组服务:

XML—(Default) User/group service persisted as XML
User/group service persisted in database via JDBC
LDAP—User/group service obtained from an LDAP repository

还可以向GeoServer添加其他服务，例如 AuthKey 扩展提供的服务。

XML user/group service

XML用户/组服务将用户/组数据库保存在XML文件中。这是GeoServer的默认行为。

该服务将用户数据库表示为XML，并与此XML schema模式相对应。

XML用户/组文件users.xml位于GeoServer数据目录security/usergroup//users.xml中，其中是用户/组服务的名称。

以下是默认GeoServer配置附带的users.xml的内容:

<?xml version="1.0" encoding="UTF-8"?>
<userRegistry version="1.0" xmlns="http://www.geoserver.org/security/users">
    <users>
        <user enabled="true" name="admin" password="digest1:D9miJH/hVgfxZJscMafEtbtliG0ROxhLfsznyWfG38X2pda2JOSV4POi55PQI4tw"/>
    </users>
    <groups/>
</userRegistry>

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)示例如下:

<userGroupService>
  <id>52857278:13c7ffd66a8:-7ffd</id>
  <name>default</name>
  <className>org.geoserver.security.xml.XMLUserGroupService</className>
  <fileName>users.xml</fileName>
  <checkInterval>10000</checkInterval>
  <validating>true</validating>
  <passwordEncoderName>digestPasswordEncoder</passwordEncoderName>
  <passwordPolicyName>default</passwordPolicyName>
</userGroupService>

角色

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文件中。

<roleService>
    <id>52857278:13c7ffd66a8:-7ffc</id>
    <name>default</name>
    <className>org.geoserver.security.xml.XMLRoleService</className>
    <fileName>roles.xml</fileName>
    <checkInterval>10000</checkInterval>
    <validating>true</validating>
    <adminRoleName>ADMIN</adminRoleName>
    <groupAdminRoleName>GROUP_ADMIN</groupAdminRoleName>
</roleService>

在本例中，赋予角色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 version="1.0" encoding="UTF-8"?>
<roleRegistry version="1.0" xmlns="http://www.geoserver.org/security/roles">
    <roleList>
        <role id="ADMIN"/>
        <role id="GROUP_ADMIN"/>
    </roleList>
    <userList>
        <userRoles username="admin">
            <roleRef roleID="ADMIN"/>
        </userRoles>
    </userList>
    <groupList/>
</roleRegistry>

该配置包含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()

角色服务与用户/组

计算用户角色

下图说明了用户/组服务和角色服务如何交互以计算用户角色。

在从用户/组服务中获取启用的用户时，必须标识分配给该用户的角色。鉴定程序为:

获取该用户user的所有已启用组。如果一个组被禁用，它将被丢弃。
获取与该用户关联的所有角色role，并将角色添加到结果集中。
对于用户所属的每个已启用组，获取与该组关联的所有角色，并将角色添加到结果集中。
对于结果集中的每个角色，获取所有祖先角色并将这些角色添加到结果集中。
根据需要个性化结果集中的每个角色。
如果结果集中存在本地admin角色，则添加角色ROLE_ADMINISTRATOR。
如果结果集中存在本地组admin角色，则添加角色ROLE_GROUP_ADMIN。

用户凭证的身份验证

用户/组服务主要用于身份验证。身份验证链Authentication chain中的身份验证提供者可以使用user/group service对用户凭证进行身份验证。

GeoServer默认的安全配置

认证

Authentication chain

在身份验证中涉及三组GeoServer资源:

web 管理界面
OWS服务的认证
REST接口服务的认证

了解身份验证链有助于解释GeoServer身份验证是如何工作的。身份验证链处理请求并应用某些身份验证机制。认证机制的例子包括:

Username/password：通过在外部用户数据库中查找用户信息来执行身份验证
Browser cookie：通过识别先前发送的浏览器cookie(也称为“Remember Me”)执行身份验证
LDAP：对LDAP数据库执行身份验证
Anonymous：本质上不执行身份验证，允许请求在没有任何凭据的情况下继续进行

在给定时间，GeoServer中可能有多个身份验证机制处于活动状态。下图说明了通用请求的流程。

在将请求分派给适当的服务或处理程序之前，GeoServer首先通过身份验证链过滤请求。请求按顺序传递给链中的每个机制，每个机制都有机会对请求进行身份验证。如果链中的一个机制能够成功地进行身份验证，则请求转到正常处理。否则，不会进一步路由请求，并向用户返回一个授权错误(通常是HTTP 401)。

过滤链和执行链

在GeoServer中，身份验证链实际上由两条链组成：

filter chain：它们决定是否需要对请求进行进一步的身份验证；
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.`
`/wms	(?=.*request=getmap)(?=.format=image/png).`
`/wms	(?=.*request=getmap)(?!.format=image/png).`

OWS和REST服务的认证

OWS和REST服务是无状态的，没有固有的“会话”意识，因此这些服务的身份验证方案要求客户端在每个请求上提供凭据。也就是说，支持“会话集成”，这意味着如果服务器上已经存在会话(来自并发认证的web管理会话)，它将用于身份验证。此方案允许GeoServer避免OWS和REST服务创建会话的开销。

默认GeoServer配置附带了对服务的HTTP基本身份验证的支持。

典型的认证过程如下:

用户在不提供任何凭据的情况下发出服务请求
如果用户正在访问不安全的资源，则正常处理请求
如果用户正在访问受保护的资源:
- 将HTTP 401状态码发送回客户端，通常强制客户端提示输入凭据。
- 然后，在包含适当凭据的情况下重复服务请求，通常在HTTP报头中，就像在Basic Authentication中一样。
- 如果用户有足够的权限访问资源，请求将被正常处理，否则，将向客户端返回一个HTTP 404状态码。
后续请求应包括原始用户凭据。

OWS服务的认证链如下所示:

在这个例子中，过滤器链由三个过滤器组成:

Session：会话，执行会话集成，识别现有会话(但不创建新会话)
Basic Auth：从请求HTTP报头提取基本身份验证凭据
Anonymous：处理匿名访问

提供者链由两个提供者组成:

Root—Root帐户有一个特殊的“超级用户”提供者。由于很少使用此帐户，因此很少调用此提供程序。
Username/password—对用户数据库进行用户名/密码认证

示例：

匿名请求WMS服务的GetCapabilities
- 会话筛选器查找现有会话，但没有找到，因此继续处理。
- 基本认证筛选器在请求中查找基本授权标头，但由于请求是匿名的，因此筛选器没有找到。
- 最后，Anonymous过滤器以匿名方式执行并验证请求。
由于GetCapabilities是一个“发现”操作，因此它通常不会被锁定，即使在安全的服务器上也是如此。假设这里是这种情况，则匿名请求成功，并向客户端返回功能响应。不调用提供程序链。
安全层的匿名WMS GetMap请求

此示例显示了当WMS客户端为安全层发出匿名GetMap请求时调用的过程。

该链的执行完全如上所述。
- 会话筛选器查找现有会话，但没有找到，因此继续处理。
- 基本认证筛选器在请求中查找基本授权标头，但由于请求是匿名的，因此筛选器没有找到。
- 最后，Anonymous过滤器以匿名方式执行并验证请求。
然而，在这种情况下，被访问的层是一个受保护的资源，因此GetMap请求的处理失败。服务器返回一个带有HTTP 401状态码的异常，这通常会触发客户端向用户呈现。
带有用户提供凭据的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目录中。该文件包含将服务操作映射到已定义角色的规则列表。指定规则的语法如下所示

30 KiB

Raw Permalink Blame History

GeoServer Security

1. Security 设置

密码

Password-based encryption

可逆加密

密钥和密钥库

密码策略

参数化的密码

角色系统

用户与组

用户/组服务

角色

角色服务

角色服务与用户/组

认证

Authentication chain

OWS和REST服务的认证

认证的提供者

服务安全

1. Key authentication

2. CAS

30 KiB Raw Permalink Blame History Unescape Escape

GeoServer Security

1. Security 设置

密码

Password-based encryption

可逆加密

密钥和密钥库

密码策略

参数化的密码

角色系统

用户与组

用户/组服务

角色

角色服务

角色服务与用户/组

认证

Authentication chain

OWS和REST服务的认证

认证的提供者

服务安全

1. Key authentication

2. CAS

30 KiB

Raw Permalink Blame History