mod_authz_core
描述: | 核心授权 |
状态: | Base |
模块标识符: | authz_core_module |
源文件: | mod_authz_core.c |
兼容性: | 可在 Apache HTTPD 2.3 及更高版本中使用 |
摘要
此模块提供核心授权功能,以便允许或拒绝经过身份验证的用户访问 web 站点的某些部分。mod_authz_core提供注册各种授权提供程序的功能。它通常与身份验证提供程序模块(如mod_authn_file)和授权模块(如mod_authz_user)一起使用。它还允许将高级逻辑应用于授权处理。
授权容器
授权容器指令<RequireAll>,<RequireAny>和<RequireNone>可以相互组合,并与要求指令组合以表示复杂的授权逻辑。
下面的 example 表示以下授权逻辑。在 order 中访问资源,用户必须是superadmin
用户,或者属于admins
group 和Administrators
LDAP group,并且属于sales
group 或具有 LDAP dept
属性sales
。此外,在_to 访问资源时,用户不得属于temps
group 或 LDAP group Temporary Employees
。
<Directory "/www/mydocs"> <RequireAll> <RequireAny> Require user superadmin <RequireAll> Require group admins Require ldap-group "cn=Administrators,o=Airius" <RequireAny> Require group sales Require ldap-attribute dept="sales" </RequireAny> </RequireAll> </RequireAny> <RequireNone> Require group temps Require ldap-group "cn=Temporary Employees,o=Airius" </RequireNone> </RequireAll> </Directory>
要求指令
mod_authz_core提供了一些可与要求指令一起使用的通用授权提供程序。
要求环境
env
提供程序允许根据环境变量的存在来控制对服务器的访问。指定Require env env-variable
时,如果环境变量 env-variable 存在,则允许请求访问。服务器提供了使用mod_setenvif提供的指令基于 client 请求的特性以灵活的方式设置环境变量的功能。因此,此指令可用于允许基于 clients User-Agent
(浏览器类型),Referer
或其他 HTTP 请求标头字段等因素进行访问。
SetEnvIf User-Agent "^KnockKnock/2.0" let_me_in <Directory "/docroot"> Require env let_me_in </Directory>
在这种情况下,将允许具有以KnockKnock/2.0
开头的 user-agent string 的浏览器进行访问,并且将拒绝所有其他浏览器。
当服务器通过内部子请求查找路径(例如查找DirectoryIndex或使用mod_autoindex生成目录列表)时,子请求中不会继承 per-request 环境变量。此外,由于 API 阶段mod_setenvif采取行动,子请求中不会单独评估SetEnvIf 之后指令。
全部要求
all
提供程序模仿以前由'Allow from all'和'Deny from all'指令提供的功能。此提供程序可以使用“已授予”或“已拒绝”的两个 arguments 之一。以下示例将授予或拒绝所有请求的访问权限。
Require all granted
Require all denied
需要方法
method
提供程序允许在授权决策中使用 HTTP 方法。 GET 和 HEAD 方法被视为等效方法。 TRACE 方法不可用于此提供程序,请改用TraceEnable。
以下 example 仅允许 GET,HEAD,POST 和 OPTIONS 请求:
Require method GET POST OPTIONS
以下 example 将允许 GET,HEAD,POST 和 OPTIONS 请求而无需身份验证,并且需要所有其他方法的有效用户:
<RequireAny> Require method GET POST OPTIONS Require valid-user </RequireAny>
要求 expr
expr
提供程序允许基于任意表达式的授权决策。
Require expr "%{TIME_HOUR} -ge 9 && %{TIME_HOUR} -le 17"
<RequireAll> Require expr "!(%{QUERY_STRING} =~ /secret/)" Require expr "%{REQUEST_URI} in { '/example.cgi', '/other.cgi' }" </RequireAll>
Require expr "!(%{QUERY_STRING} =~ /secret/) && %{REQUEST_URI} in { '/example.cgi', '/other.cgi' }"
语法在ap_expr文档中描述。在 httpd 2.4.16 之前,必须省略周围的 double-quotes。
通常,在验证之前评估表达式。但是,如果表达式返回 false 并且 references 变量%{REMOTE_USER}
,则将执行身份验证,表达式将为 re-evaluated。
创建授权提供商别名
可以在 configuration 文件中创建扩展授权提供程序,并为其分配别名 name。然后,可以通过要求指令以与基本授权提供程序相同的方式引用别名提供程序。除了能够为扩展提供程序创建和别名外,它还允许多个位置引用相同的扩展授权提供程序。
示例
下面的 example 根据 ldap-group 授权提供程序创建两个不同的 ldap 授权提供程序别名。此 example 允许单个授权位置检查多个 ldap 主机中的 group 成员身份:
<AuthzProviderAlias ldap-group ldap-group-alias1 "cn=my-group,o=ctx"> AuthLDAPBindDN "cn=youruser,o=ctx" AuthLDAPBindPassword yourpassword AuthLDAPUrl "ldap://ldap.host/o=ctx" </AuthzProviderAlias> <AuthzProviderAlias ldap-group ldap-group-alias2 "cn=my-other-group,o=dev"> AuthLDAPBindDN "cn=yourotheruser,o=dev" AuthLDAPBindPassword yourotherpassword AuthLDAPUrl "ldap://other.ldap.host/o=dev?cn" </AuthzProviderAlias> Alias "/secure" "/webpages/secure" <Directory "/webpages/secure"> Require all granted AuthBasicProvider file AuthType Basic AuthName LDAP_Protected_Place #implied OR operation Require ldap-group-alias1 Require ldap-group-alias2 </Directory>
AuthMerging 指令
描述: | 控制每个 configuration 部分的授权逻辑与前面的 configuration 部分的组合方式。 |
句法: | AuthMerging Off \| And \| Or |
默认: | AuthMerging Off |
Context: | 目录,.htaccess |
覆盖: | AuthConfig |
状态: | Base |
模块: | mod_authz_core |
启用授权后,除非指定了一组不同的授权指令,否则它通常由每个后续configuration 部分继承。这是默认操作,对应于AuthMerging Off
的显式设置。
但是,在合并 configuration 部分时,可能存在需要将 configuration 部分的授权与其前任授权组合的情况。这种情况有两种选择,And
和Or
。
当 configuration 部分包含AuthMerging And
或AuthMerging Or
时,其授权逻辑与最近的前任(根据 configuration 部分的整个 order)的授权逻辑相结合,后者也包含授权逻辑,就好像这两个部分共同包含在<RequireAll>或<RequireAny>指令中一样,分别。
AuthMerging
的设置不会在其出现的 configuration 部分之外继承。在以下 example 中,只有属于 group alpha
的用户才能访问/www/docs
。属于alpha
或beta
组的用户可以访问/www/docs/ab
。但是,AuthMerging
的默认Off
设置适用于/www/docs/ab/gamma
的<Directory> configuration 部分,因此该部分的授权指令会覆盖前面部分的那些。因此,只有属于 group gamma
的用户才能访问/www/docs/ab/gamma
。
<Directory "/www/docs"> AuthType Basic AuthName Documents AuthBasicProvider file AuthUserFile "/usr/local/apache/passwd/passwords" Require group alpha </Directory> <Directory "/www/docs/ab"> AuthMerging Or Require group beta </Directory> <Directory "/www/docs/ab/gamma"> Require group gamma </Directory>
<AuthzProviderAlias>指令
描述: | 附上一组指令,这些指令表示基本授权提供程序的扩展,并由指定的别名引用 |
句法: | <AuthzProviderAlias baseProvider Alias Require-Parameters>...</AuthzProviderAlias> |
Context: | 服务器配置 |
状态: | Base |
模块: | mod_authz_core |
<AuthzProviderAlias>
和</AuthzProviderAlias>
用于包含一组授权指令,该指令可由别名 name 使用指令要求引用。
如果 Require-Parameters 中需要多个参数,则必须用引号括起来。否则,只考虑第一个。
# In this example, for both addresses to be taken into account, they MUST be enclosed # between quotation marks <AuthzProviderAlias ip blacklisted-ips "XXX.XXX.XXX.XXX YYY.YYY.YYY.YYY"> </AuthzProviderAlias> <Directory "/path/to/dir"> <RequireAll> Require not blacklisted-ips Require all granted </RequireAll> </Directory>
AuthzSendForbiddenOnFailure 指令
描述: | 如果身份验证成功但授权失败,则发送'403 FORBIDDEN'而不是'401 UNAUTHORIZED' |
句法: | AuthzSendForbiddenOnFailure On\|Off |
默认: | AuthzSendForbiddenOnFailure Off |
Context: | 目录,.htaccess |
状态: | Base |
模块: | mod_authz_core |
兼容性: | 可在 Apache HTTPD 2.3.11 及更高版本中使用 |
如果身份验证成功但授权失败,Apache HTTPD 将默认响应 HTTP 响应 code'401 UNAUTHORIZED'。这通常会导致浏览器再次向用户显示密码对话框,这在所有情况下都不需要。AuthzSendForbiddenOnFailure
允许将响应 code 更改为'403 FORBIDDEN'。
安全警告
在缺少授权的情况下修改响应会削弱密码的安全性,因为它向可能的攻击者透露,他猜测的密码是正确的。
需要指令
描述: | 测试经过身份验证的用户是否由授权提供程序授权。 |
句法: | Require[not] entity-name[entity-name]... |
Context: | 目录,.htaccess |
覆盖: | AuthConfig |
状态: | Base |
模块: | mod_authz_core |
此指令根据特定授权提供程序和指定的限制来测试经过身份验证的用户是否已获得授权。mod_authz_core提供以下通用授权提供程序:
Require all granted
无条件允许访问。Require all denied
无条件拒绝访问。Require env env-var[env-var]...
仅当设置了一个给定的环境变量时才允许访问。Require method http-method[http-method]...
仅允许对给定的 HTTP 方法进行访问。Require expr expression
如果表达式求值为 true,则允许访问。
mod_authz_user,mod_authz_host和mod_authz_groupfile提供的一些允许的语法是:
Require user userid[userid]...
只有指定的用户才能访问该资源。Require group group-name[group-name]...
只有命名组中的用户才能访问该资源。Require valid-user
所有有效用户都可以访问该资源。Require ip 10 172.20 192.168.2
指定 IP 地址范围内的客户端可以访问该资源。
实现 require 选项的其他授权模块包括mod_authnz_ldap,mod_authz_dbm,mod_authz_dbd,mod_authz_owner和mod_ssl。
在大多数情况下,对于完整的身份验证和授权 configuration,Require
必须伴随AuthName 指令,进行 AuthType和AuthBasicProvider或AuthDigestProvider 指令指令,和目录 AuthGroupFile(用于定义用户和组)等指令才能正常工作。例:
AuthType Basic AuthName "Restricted Resource" AuthBasicProvider file AuthUserFile "/web/users" AuthGroupFile "/web/groups" Require group admin
以这种方式应用的访问控制对所有**方法都有效.**这是通常需要的.**如果您希望仅对特定方法应用访问控制,同时保留其他方法不受保护,则将Require
语句放入<Limit>部分。
Require
指令的结果可以通过使用not
选项来否定。与其他否定授权指令<RequireNone>
一样,当Require
指令被否定时,它只能失败或 return 中性结果,因此可能永远不会独立授权请求。
在下面的示例中,alpha
和beta
组中的所有用户都被授权,但同样位于reject
group 的用户除外。
<Directory "/www/docs"> <RequireAll> Require group alpha beta Require not group reject </RequireAll> </Directory>
当多个Require
指令在单个configuration 部分中使用且未包含在另一个授权指令(如<RequireAll>)中时,它们隐式包含在<RequireAny>指令中。因此,授权用户的第一个授权整个请求,并忽略后续的Require
指令。
安全警告
在地点部分中设置与文件系统提供的内容重叠的授权指令时要小心。默认情况下,这些configuration 部分覆盖目录和Files部分中的授权 configuration。
AuthMerging指令可用于控制如何合并授权 configuration 部分。
参见
- 访问控制 howto
- 授权容器
- mod_authn_core
- mod_authz_host
<RequireAll>指令
描述: | 附上一组 none 授权指令,其中 none 必须失败,并且至少有一个必须成功才能使封闭指令成功。 |
句法: | <RequireAll>...</RequireAll> |
Context: | 目录,.htaccess |
覆盖: | AuthConfig |
状态: | Base |
模块: | mod_authz_core |
<RequireAll>
和</RequireAll>
用于包含 none 必须失败的 group 授权指令,并且至少有一个必须在 order 中成功才能使<RequireAll>
指令成功。
如果<RequireAll>
指令中包含的指令失败,并且至少有一个成功,则<RequireAll>
指令成功。如果 none 成功且 none 失败,则返回中性结果。在所有其他情况下,它失败了。
参见
- 授权容器
- 身份验证,授权和访问控制
<RequireAny>指令
描述: | 附上一组授权指令,其中一个必须成功才能使封闭指令成功。 |
句法: | <RequireAny>...</RequireAny> |
Context: | 目录,.htaccess |
覆盖: | AuthConfig |
状态: | Base |
模块: | mod_authz_core |
<RequireAny>
和</RequireAny>
用于包含一组授权指令,其中一个必须在 order 中成功才能使<RequireAny>
指令成功。
如果<RequireAny>
指令中包含的一个或多个指令成功,则<RequireAny>
指令成功。如果 none 成功且 none 失败,则返回中性结果。在所有其他情况下,它失败了。
因为否定的授权指令无法_return 成功的结果,它们不能显着影响<RequireAny>
指令的结果。(最多可能导致指令在失败并且所有其他指令返回中性的情况下失败 value.)因此在<RequireAny>
指令中不允许否定授权指令。
参见
- 授权容器
- 身份验证,授权和访问控制
<RequireNone>指令
描述: | 附上 group 授权指令,其中 none 必须成功才能使封闭指令失败。 |
句法: | <RequireNone>...</RequireNone> |
Context: | 目录,.htaccess |
覆盖: | AuthConfig |
状态: | Base |
模块: | mod_authz_core |
<RequireNone>
和</RequireNone>
用于包含一组 group 授权指令,其中 none 必须在 order 中成功才能使<RequireNone>
指令失败。
如果<RequireNone>
指令中包含的一个或多个指令成功,则<RequireNone>
指令失败。在所有其他情况下,它返回中性结果。因此,与其他否定的授权指令Require not
一样,它永远不能独立地授权请求,因为它永远不会_return 成功的结果。但是,可以使用它来限制有权访问资源的用户集。
因为否定的授权指令无法_return 成功的结果,它们不能显着影响<RequireNone>
指令的结果。因此,在<RequireNone>
指令中不允许否定授权指令。
参见
- 授权容器
- 身份验证,授权和访问控制