层安全性¶
地理服务器允许按层确定访问。
备注
层安全和 服务安全 不能组合。例如,不能仅为一个特定层指定对特定OWS服务的访问。
提供对层的访问链接到 roles .层和角色在名为 layers.properties
,位于 security
地理服务器数据目录中的目录。该文件包含控制对工作区和层的访问的规则。
备注
geoserver中的默认层安全配置允许任何匿名用户从任何层读取数据,但只允许管理员用户编辑数据。
规则¶
层安全规则的语法可以遵循三种不同的模式 ([]
表示可选参数)::
globalLayerGroup.permission=role[,role2,...]
workspace.layer.permission=role[,role2,...]
workspace.workspaceLayerGroup.permission=role[,role2,...]
参数包括:
globalLayerGroup
-全局层组的名称(没有与其关联的工作区)。workspace
-工作区的名称。通配符*
用于指示所有工作区。layer
-资源的名称(featureType/coverage/etc…)。通配符*
用于指示所有层。workspaceLayerGroup
-工作区特定层组的名称。permission
-访问权限/模式的类型。r
-读取访问权限w
-写入访问权限a
-管理员访问
见 访问模式 了解更多详细信息。
role[,role2,...]
是预定义角色的名称。通配符*
用于指示权限应用于所有用户,包括匿名用户。
备注
如果工作区或层名称应该包含点,则可以使用双反斜杠对其进行转义。 (\\
)。例如,如果一个图层命名为 layer.with.dots
可以使用规则的以下语法:
topp.layer\\.with\\.dots.r=role[,role2,...]
层安全的一般规则:
每个条目必须具有工作区、层和权限值的唯一组合。
如果未指定全局级别的权限,则假定全局权限允许读/写访问。
如果未指定工作区的权限,则它从全局规范继承权限。
如果未指定层的权限,则它从其工作区规范继承除WMS之外的所有协议中的权限(在层组规则扮演角色的情况下,请参见下文)。
如果用户属于多个角色,则 限制最小 将应用他们继承的权限。
对于WMS,还将通过考虑层的包含层组来保护层。特别地:
规则与 单曲 层组只影响组本身,而不影响其内容。 单曲 模式被认为只是层列表的别名,没有包含。
具有其他类型组的规则( 命名树 , 容器树 , 地球观测树 )也会影响包含的图层和嵌套的图层组。如果组不可访问,则该组中包含的层和组也将不可访问。唯一的例外是,当可访问的另一个图层组包含相同的图层或嵌套组时,在这种情况下,它们将显示在允许的组下。
在允许访问层时,工作区规则优先于全局层组规则。
当允许访问层时,层规则优先于所有层组规则。
下表汇总了层组行为,具体取决于它们是在公共环境还是安全环境中使用:
Mode |
公众行为 |
限制行为 |
---|---|---|
Single |
看起来像一个独立的层,可以直接请求并作为层列表的别名。层在根级别也可见 |
根本不控制层访问 |
不透明容器 |
看起来像一个独立的层,可以直接请求并作为层列表的别名。其中的层不可用于WMS请求 |
与公共行为相同 |
命名树 |
包含的层在功能文档中作为子级可见,该名称可用作请求所有层的快捷方式。 |
限制对组的访问也限制包含的层,除非另一个“树”组允许访问同一层。 |
容器树 |
与“命名树”相同,但没有在功能文档中发布的名称,因此无法直接请求。 |
与“命名树”相同 |
目录模式¶
这个 layers.properties
文件可能包含另一个指令,该指令指定当访问安全层时,没有必要的特权,GeoServer将如何公布安全层以及如何进行操作。参数是 mode
通常被称为“目录模式”。
语法是::
mode=option
option
可能是以下三个值之一:
期权 |
描述 |
---|---|
|
(默认) 隐藏用户不具有读取权限的层,并且在用户没有写入权限时,其行为就像层是只读的。功能文档将不包含当前用户无法访问的层。这是最高的安全模式。因此,它可能不能很好地与客户,如udig或谷歌地球。 |
|
允许自由访问元数据,但HTTP 401代码满足访问实际数据的任何尝试(它强制大多数客户机显示身份验证对话框)。功能文档包含完整的层列表。DescribeFeatureType和DescribeCoverage操作成功工作。这种模式对udig或google earth等客户机很好。 |
|
隐藏用户无法从功能文档中读取的层,但触发任何其他访问数据或元数据的尝试的身份验证。如果您不希望世界看到您的某些数据的存在,但您仍然希望选定的具有数据访问链接的人员在身份验证后获取数据,则此选项非常有用。 |
访问模式¶
访问模式定义在特定工作区/层上应授予特定角色的访问级别。有三种访问模式:
r
- 读取模式 (从工作区/层读取数据)w
- 写入模式 (将数据写入工作区/层)a
- 管理模式 (访问和修改工作区/层的配置)
关于上述访问模式的一些说明:
写并不意味着读,但管理意味着写 and 阅读。
读写应用于层的数据,而管理应用于层的配置。
由于管理模式只涉及层的配置,因此任何OGC服务请求都不需要配置。
备注
目前,只能将管理权限分配给整个工作区,而不能分配给特定的层。
实例¶
下面的例子说明了一些可能的层限制和相应的规则。
保护单个工作区和单个层¶
下面的示例演示如何将geoserver配置为主要的只读服务器:
*.*.r=*
*.*.w=NO_ONE
private.*.r=TRUSTED_ROLE
private.*.w=TRUSTED_ROLE
topp.congress_district.w=STATE_LEGISLATORS
角色到权限的映射如下:
角色 |
private.* |
topp.* |
topp.congress_district |
(所有其他工作区) |
---|---|---|---|---|
|
(无) |
W |
(无) |
W |
|
顺时针方向 |
R |
R |
R |
|
(无) |
R |
顺时针方向 |
R |
(所有其他用户) |
(无) |
R |
R |
R |
备注
特定工作空间规则 private.*.r=TRUSTED_ROLE
将优先于更通用的规则 *.*.r=*
。当发出读取图层的请求时 private:vulnerable_infrastructure
可用的最具体的规则用于控制访问。在本例中,工作区规则 private.*.r=TRUSTED_ROLE
是最具体的,并且只会授予具有TRUSTED_ROLE的用户 r
访问并能够阅读 private:vulnerable_infrastructure
一层。不会授予没有Trusted_Role的其他用户 r
访问,并且将无法访问 private:vulnerable_infrastructure
一层。
锁定geoserver¶
以下示例演示如何锁定geoserver::
*.*.r=TRUSTED_ROLE
*.*.w=TRUSTED_ROLE
topp.*.r=*
army.*.r=MILITARY_ROLE,TRUSTED_ROLE
army.*.w=MILITARY_ROLE,TRUSTED_ROLE
角色到权限的映射如下:
角色 |
topp.* |
army.* |
(所有其他工作区) |
---|---|---|---|
|
顺时针方向 |
顺时针方向 |
顺时针方向 |
|
R |
顺时针方向 |
(无) |
(所有其他用户) |
R |
(无) |
(无) |
提供受限的管理访问¶
除了完全管理员角色之外,以下功能还提供对单个工作区中特定角色的管理访问:
*.*.a=ROLE_ADMINISTRATOR
topp.*.a=ROLE_TOPP_ADMIN,ROLE_ADMINISTRATOR
管理多级权限¶
以下示例演示如何使用全局、工作区和层级权限配置geoserver::
*.*.r=TRUSTED_ROLE
*.*.w=NO_ONE
topp.*.r=*
topp.states.r=USA_CITIZEN_ROLE,LAND_MANAGER_ROLE,TRUSTED_ROLE
topp.states.w=NO_ONE
topp.poly_landmarks.w=LAND_MANAGER_ROLE
topp.military_bases.r=MILITARY_ROLE
topp.military_bases.w=MILITARY_ROLE
角色到权限的映射如下:
角色 |
topp.states |
topp.poly_landmarks |
topp.military_bases |
顶部(所有其他层) |
(所有其他工作区) |
---|---|---|---|---|---|
|
W |
R |
(无) |
W |
W |
|
R |
R |
(无) |
R |
R |
|
(无) |
R |
顺时针方向 |
R |
(无) |
|
R |
R |
(无) |
R |
(无) |
|
R |
顺时针方向 |
(无) |
R |
(无) |
(所有其他用户) |
(无) |
R |
(无) |
R |
(无) |
备注
入口 topp.states.w=NO_ONE
不需要,因为此权限将从全局级别继承(条目 *.*.w=NO_ONE
)
无效配置¶
以下示例无效,因为工作区、层和权限组合不唯一:
topp.state.rw=ROLE1
topp.state.rw=ROLE2,ROLE3
WMS中按层组划分的安全性¶
为了澄清这一点,我们假设以下开始情况,其中所有层和组都可见:
root
+- namedTreeGroupA
| | ws1:layerA
| └ ws2:layerB
+- namedTreeGroupB
| | ws2:layerB
| └ ws1:layerC
+- layerD
+- singleGroupC (contains ws1:layerA and layerD when requested)
下面是几个基于不同安全规则的结构更改示例。
拒绝访问
namedTreeGroupA
签署人:namedTreeGroupA.r=ROLE_PRIVATE
将为匿名用户提供以下功能树:
root +- namedTreeGroupB | | ws2:layerB | └ ws1:layerC +- layerD +- singleGroupC (contains only layerD when requested)
拒绝访问
namedTreeGroupB
签署人:namedTreeGroupB.r=ROLE_PRIVATE
将为匿名用户提供以下功能树:
root +- namedTreeGroupA | | ws1:layerA | └ ws2:layerB +- layerD +- singleGroupC (contains ws1:layerA and layerD when requested)
拒绝访问
singleGroupC
签署人:singleGroupC.r=ROLE_PRIVATE
将为匿名用户提供以下功能树:
root +- namedTreeGroupA | | ws1:layerA | └ ws2:layerB +- namedTreeGroupB | | ws2:layerB | └ ws1:layerC +- layerD
拒绝访问所有内容,但允许通过以下方式显式访问NamedTreeGroupA::
nameTreeGroupA.r=* *.*.r=PRIVATE *.*.w=PRIVATE
将为匿名用户提供以下功能树:
root +- namedTreeGroupA | ws1:layerA └ ws2:layerB
拒绝访问
nameTreeGroupA
和namedTreeGroupB
但明确允许访问ws1:layerA
**namedTreeGroupA.r=ROLE_PRIVATE namedTreeGroupB.r=ROLE_PRIVATE ws1.layerA.r=*
将向匿名用户提供以下功能树(注意ws1:layera如何弹出到根目录)::
root +- ws1:layerA +- layerD
拒绝访问
nameTreeGroupA
和namedTreeGroupB
但明确允许WS2中的所有层(工作空间规则覆盖全局组规则):namedTreeGroupA.r=ROLE_PRIVATE namedTreeGroupB.r=ROLE_PRIVATE ws2.*.r=*
将向匿名用户提供以下功能树(注意ws1:layerB如何弹出到根目录)::
root +- ws2:layerB +- layerD +- singleGroupC