diff options
| author | Bradley Nicholes <bnicholes@apache.org> | 2006-01-11 14:30:28 +0000 |
|---|---|---|
| committer | Bradley Nicholes <bnicholes@apache.org> | 2006-01-11 14:30:28 +0000 |
| commit | 9fed4c73d7d572fa468b407c44a1923e520f98ae (patch) | |
| tree | f0742c9a64ec0809f85318194f4aa74f6e5110fe /docs/manual/mod/mod_authz_core.xml | |
| parent | bb2af228cdf3372ce92a7764928b641751c32b61 (diff) | |
| download | httpd-9fed4c73d7d572fa468b407c44a1923e520f98ae.tar.gz | |
Authz refactoring
Merge from branches/authz-dev
Basically here is a list of what has been done:
- Convert all of the authz modules from hook based to provider based
- Remove the ap_requires field from the core_dir_config structure
- Remove the function ap_requires() since its functionality is no
longer supported or necessary in the refactoring
- Remove the calls to ap_some_auth_required() in the core request
handling to allow the hooks to be called in all cases.
- Add the new module mod_authz_core which will act as the authorization
provider vector and contain common authz directives such as 'Require',
'Reject' and '<RequireAlias>'
- Add the new module mod_authn_core which will contain common
authentication directives such as 'AuthType', 'AuthName' and
'<AuthnProviderAlias>'
- Move the check for METHOD_MASK out of the authz providers and into
the authz_core provider vector
- Define the status codes that can be returned by the authz providers
as AUTHZ_DENIED, AUTHZ_GRANTED and AUTHZ_GENERAL_ERROR
- Remove the 'Satisfy' directive
- Implement the '<RequireAll>', '<RequireOne>' block directives to
handle the 'and' and 'or' logic for authorization.
- Remove the 'AuthzXXXAuthoritative' directives from all of the authz
providers
- Implement the 'Reject' directive that will deny authorization if the
argument is true
- Fold the 'Reject' directive into the '<RequireAll>', '<RequireOne>'
logic
- Reimplement the host based authorization functionality provided by
'allow', 'deny' and 'order' as authz providers
- Remove the 'allow', 'deny' and 'order' directives
- Merge mod_authn_alias into mod_authn_core
- Add '<RequireAlias>' functionality which is similar to
'<AuthnProviderAlias>' but specific to authorization aliasing
- Remove all of the references to the 'authzxxxAuthoritative'
directives from the documentation
- Remove the 'Satisfy' directive from the documentation
- Remove 'Allow', 'Deny', 'Order' directives from the documentation
- Document '<RequireAll>', '<RequireOne>', 'Reject' directives
- Reimplement the APIs ap_auth_type(), ap_auth_name() as optional
functions and move the actual implementation into mod_authn_core
- Reimplement the API ap_some_auth_required() as an optional function
and move the actual implementation into mod_authz_core
Major Changes:
- Added the directives <RequireAll>, <RequireOne>, <RequireAlias>,
Reject
- Expanded the functionality of the directive 'Require' to handle all
authorization and access control
- Added the new authz providers 'env', 'ip', 'host', 'all' to handle
host-based access control
- Removed the directives 'Allow', 'Deny', 'Order', 'Satisfy',
'AuthzXXXAuthoritative'
- Removed the ap_require() API
- Moved the directives 'AuthType', 'AuthName' out of mod_core and into
mod_authn_core
- Moved the directive 'Require' out of mod_core and into
mod_authz_core
- Merged mod_authn_alias into mod_authn_core
- Renamed mod_authz_dbm authz providers from 'group' and 'file-group'
to 'dbm-group' and 'dbm-file-group'
Benefits:
- All authorization and access control is now handle through two
directives, 'Require' and 'Reject'
- Authorization has been expanded to allow for complex 'AND/OR' control
logic through the directives '<RequireAll>' and '<RequireOne>'
- Configuration is now much simpler and consistent across the board
- Other modules like mod_ssl and mod_proxy should be able to plug into
and take advantage of the same provider based authorization mechanism
by implementing their own providers
Issues:
- Backwards compatibility between 2.2 and 2.3 configurations will be
broken in the area of authorization and access control due to the fact
that the directives 'allow', 'deny', 'order' and 'satisfy' have been
removed. When moving from 2.2 to 2.3 these directives will have to be
changed to 'Require all granted', 'Require all denied' or some variation
of the authz host-based providers.
- Existing third party authorization modules will have to adapt to the
new structure.
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@368027 13f79535-47bb-0310-9956-ffa450edef68
Diffstat (limited to 'docs/manual/mod/mod_authz_core.xml')
| -rw-r--r-- | docs/manual/mod/mod_authz_core.xml | 222 |
1 files changed, 222 insertions, 0 deletions
diff --git a/docs/manual/mod/mod_authz_core.xml b/docs/manual/mod/mod_authz_core.xml new file mode 100644 index 0000000000..9faac243ee --- /dev/null +++ b/docs/manual/mod/mod_authz_core.xml @@ -0,0 +1,222 @@ +<?xml version="1.0"?>
+<!DOCTYPE modulesynopsis SYSTEM "../style/modulesynopsis.dtd">
+<?xml-stylesheet type="text/xsl" href="../style/manual.en.xsl"?>
+<!-- $LastChangedRevision: 151408 $ -->
+
+<!--
+ Copyright 2002-2005 The Apache Software Foundation or its licensors, as
+ applicable.
+
+ Licensed under the Apache License, Version 2.0 (the "License");
+ you may not use this file except in compliance with the License.
+ You may obtain a copy of the License at
+
+ http://www.apache.org/licenses/LICENSE-2.0
+
+ Unless required by applicable law or agreed to in writing, software
+ distributed under the License is distributed on an "AS IS" BASIS,
+ WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ See the License for the specific language governing permissions and
+ limitations under the License.
+-->
+
+<modulesynopsis metafile="mod_authz_core.xml.meta">
+
+<name>mod_authz_core</name>
+<description>Core Authorization</description>
+<status>Base</status>
+<sourcefile>mod_authz_core.c</sourcefile>
+<identifier>authz_core_module</identifier>
+<compatibility>Available in Apache 2.3 and later</compatibility>
+
+<summary>
+ <p>This module provides core authorization capabilities so that
+ authenticated users can be allowed or denied access to portions
+ of the web site. <module>mod_authz_core</module> provides the
+ functionality to register various authorization providers. It is
+ usually used in conjunction with an authentication
+ provider module such as <module>mod_authn_file</module> and an
+ authorization module such as <module>mod_authz_user</module>. It
+ also allows for "AND" and "OR" logic to be applied to the
+ authorization processing.</p>
+</summary>
+
+<directivesynopsis>
+<name>Require</name>
+<description>Selects which authenticated users can access
+a resource</description>
+<syntax>Require <var>entity-name</var> [<var>entity-name</var>] ...</syntax>
+<contextlist><context>directory</context><context>.htaccess</context>
+</contextlist>
+<override>AuthConfig</override>
+
+<usage>
+ <p>This directive selects which authenticated users can access a
+ resource. The restrictions are processed by authorization
+ modules. Some of the allowed syntaxes provided by
+ <module>mod_authz_user</module> and
+ <module>mod_authz_groupfile</module> are:</p>
+
+ <dl>
+ <dt><code>Require user <var>userid</var> [<var>userid</var>]
+ ...</code></dt>
+ <dd>Only the named users can access the resource.</dd>
+
+ <dt><code>Require group <var>group-name</var> [<var>group-name</var>]
+ ...</code></dt>
+ <dd>Only users in the named groups can access the resource.</dd>
+
+ <dt><code>Require valid-user</code></dt>
+ <dd>All valid users can access the resource.</dd>
+ </dl>
+
+ <p>Other authorization modules that implement require options
+ include <module>mod_authnz_ldap</module>,
+ <module>mod_authz_dbm</module>, <module>mod_authz_dbd</module>,
+ <module>mod_authz_host</module>, and
+ <module>mod_authz_owner</module>.</p>
+
+ <p>For a complete authentication and authorization configuration,
+ <directive>Require</directive> must be accompanied by
+ <directive module="mod_authn_core">AuthName</directive>, <directive
+ module="mod_authn_core">AuthType</directive> and
+ <directive module="mod_auth_basic">AuthBasicProvider</directive>
+ directives, and directives such as
+ <directive module="mod_authn_file">AuthUserFile</directive>
+ and <directive module="mod_authz_groupfile">AuthGroupFile</directive> (to
+ define users and groups) in order to work correctly. Example:</p>
+
+ <example>
+ AuthType Basic<br />
+ AuthName "Restricted Resource"<br />
+ AuthBasicProvider file<br />
+ AuthUserFile /web/users<br />
+ AuthGroupFile /web/groups<br />
+ Require group admin
+ </example>
+
+ <p>Access controls which are applied in this way are effective for
+ <strong>all</strong> methods. <strong>This is what is normally
+ desired.</strong> If you wish to apply access controls only to
+ specific methods, while leaving other methods unprotected, then
+ place the <directive>Require</directive> statement into a
+ <directive module="core" type="section">Limit</directive>
+ section.</p>
+
+</usage>
+
+<seealso><a href="../howto/auth.html">Authentication, Authorization,
+ and Access Control</a></seealso>
+<seealso><module>mod_authz_host</module></seealso>
+</directivesynopsis>
+
+<directivesynopsis>
+<name>Reject</name>
+<description>Rejects which authenticated users can access
+a resource</description>
+<syntax>Reject <var>entity-name</var> [<var>entity-name</var>] ...</syntax>
+<contextlist><context>directory</context><context>.htaccess</context>
+</contextlist>
+<override>AuthConfig</override>
+
+<usage>
+ <p>This directive is similar to the
+ <directive module="mod_authz_core">Require</directive> directive however
+ it rejects which authenticated users can access a resource. The
+ restrictions are processed by authorization modules. See the
+ <directive module="mod_authz_core">Require</directive> directive for details
+ about usage.</p>
+</usage>
+
+<seealso><a href="../howto/auth.html">Authentication, Authorization,
+ and Access Control</a></seealso>
+<seealso><module>mod_authz_host</module></seealso>
+</directivesynopsis>
+
+<directivesynopsis type="section">
+<name>SatisfyAll</name>
+<description>Enclose a group of authorization directives that must all
+be satisfied in order to grant access to a resource. This block allows
+for 'AND' logic to be applied to various authorization providers.</description>
+<syntax><SatisfyAll>
+... </SatisfyAll></syntax>
+<contextlist><context>directory</context><context>.htaccess</context>
+</contextlist>
+<override>AuthConfig</override>
+
+<usage>
+ <p><directive type="section">SatisfyAll</directive> and
+ <code></SatisfyAll></code> are used to enclose a group of
+ authorization directives that must all be satisfied in order to
+ grant access to a resource.</p>
+
+ <p>The <directive module="mod_authz_core">
+ <SatisfyAll></directive> block as well as the
+ <directive module="mod_authz_core"><SatisfyOne></directive> block
+ allow you to apply "AND" and "OR" logic to the authorization processing.
+ For example the following authorization block would apply the logic:</p>
+
+ <p><var>
+ if ((user == "John") || <br />
+ ((Group == "admin") && (ldap-group <ldap-object> contains auth'ed_user) &&<br />
+ ((ldap-attribute dept == "sales") ||
+ (file-group contains contains auth'ed_user))))<br />
+ then<br />
+ auth_granted<br />
+ else<br />
+ auth_denied<br />
+ </var></p>
+
+ <example>
+ <Directory /www/mydocs><br />
+ Authname ...<br />
+ AuthBasicProvider ...<br />
+ ...<br />
+ Require user John<br />
+ <SatisfyAll><br />
+ Require Group admins<br />
+ Require ldap-group cn=mygroup,o=foo<br />
+ <SatisfyOne><br />
+ Require ldap-attribute dept="sales"<br />
+ Require file-group<br />
+ </SatisfyOne><br />
+ </SatisfyAll><br />
+ </Directory><br />
+ </example>
+
+</usage>
+
+<seealso><a href="../howto/auth.html">Authentication, Authorization,
+ and Access Control</a></seealso>
+
+</directivesynopsis>
+
+<directivesynopsis type="section">
+<name>SatisfyOne</name>
+<description>Enclose a group of authorization directives that must
+satisfy at least one in order to grant access to a resource. This
+block allows for 'OR' logic to be applied to various authorization
+providers.</description>
+<syntax><SatisfyOne>
+... </SatisfyOne></syntax>
+<contextlist><context>directory</context><context>.htaccess</context>
+</contextlist>
+<override>AuthConfig</override>
+
+<usage>
+ <p><directive type="section">SatisfyOne</directive> and
+ <code></SatisfyOne></code> are used to enclose a group of
+ authorization directives that must satisfy at least one in order to
+ grant access to a resource.</p>
+
+ <p>See the <directive module="mod_authz_core">
+ <SatisfyAll></directive> directive for a usage example.</p>
+
+</usage>
+
+<seealso><a href="../howto/auth.html">Authentication, Authorization,
+ and Access Control</a></seealso>
+
+</directivesynopsis>
+
+</modulesynopsis>
|