From: André Malo Date: Thu, 16 Feb 2006 17:30:19 +0000 (+0000) Subject: update transformation X-Git-Tag: 2.3.0~2539 X-Git-Url: https://granicus.if.org/sourcecode?a=commitdiff_plain;h=25f7c48737e0d0a98f86cb1b52065a69e7d72810;p=apache update transformation git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@378311 13f79535-47bb-0310-9956-ffa450edef68 --- diff --git a/docs/manual/howto/auth.html.en b/docs/manual/howto/auth.html.en index 307a9e72d7..93276d8d68 100644 --- a/docs/manual/howto/auth.html.en +++ b/docs/manual/howto/auth.html.en @@ -36,6 +36,8 @@ person in
  • Possible problems
  • Alternate password storage
    • +
  • Using multiple providers
    • +
  • Beyond just authorization
  • More information
    • top
    @@ -54,9 +56,11 @@ module from each group.

  • mod_auth_digest
    • -
  • Authentication provider +
  • Authentication provider (see the + AuthBasicProvider and + AuthDigestProvider directives) + -

    The module mod_authnz_ldap is both an - authentication and authorization provider. The module - mod_authn_alias is not an authentication provider - in itself, but allows other authentication providers to be - configured in a flexible manner.

    +

    In addition to these modules, there are also + mod_authn_core and + mod_authz_core. These module implement core + directives that are core to all auth modules.

    -

    The module mod_authz_host provides authorization +

    The module mod_authnz_ldap is both an + authentication and authorization provider. The module + mod_authz_host provides authorization and access control based on hostname, IP address or characteristics of the request, but is not part of the authentication provider - system.

    + system. For backwards compatibility with the mod_access, there is + a new module mod_access_compat.

    You probably also want to take a look at the Access Control howto, which discusses the various ways to control access to your server.

    @@ -138,6 +146,13 @@ module from each group.

    structure of your server, in order to know where some files are kept. This should not be terribly difficult, and I'll try to make this clear when we come to that point.

    + +

    You will also need to make sure that the modules + mod_authn_core and mod_authz_core + have either been built into the httpd binary or loaded by the + httpd.conf configuration file. Both of these modules provide core + directives and functionality that are critical to the configuration + and use of authentication and authorization in the web server.

    top

    Getting it working

    @@ -368,14 +383,241 @@ person in

    Other options are available. Consult the mod_authn_dbm documentation for more details.

    +
    top
    +
    +

    Using multiple providers

    + +

    With the introduction of the new provider based authentication and + authorization architecture, you are no longer locked into a single + authentication or authorization method. In fact any number of the + providers can be mixed and matched to provide you with exactly the + scheme that meets your needs. In the following example, both the + file and ldap based authentication providers are being used.

    + +

    + <Directory /www/docs/private>
    + AuthName "Private"
    + AuthType Basic
    + AuthBasicProvider file ldap
    + AuthUserFile /usr/local/apache/passwd/passwords
    + AuthLDAPURL ldap://ldaphost/o=yourorg
    + Require valid-user +

    + +

    In this example the file provider will attempt to authenticate + the user first. If it is unable to authenticate the user, the ldap + provider will be called. This allows the scope of authentication + to be broadened if your organization implements more than + one type of authentication store. Other authentication and authorization + scenarios may include mixing one type of authentication with a + different type of authorization. For example, authenticating against + a password file yet authorizing against and ldap directory.

    + +

    Just as multiple authentication providers can be implemented, multiple + authorization methods can also be used. In this example both file group + authorization as well as ldap group authorization is being used.

    + +

    + <Directory /www/docs/private>
    + AuthName "Private"
    + AuthType Basic
    + AuthBasicProvider file
    + AuthUserFile /usr/local/apache/passwd/passwords
    + AuthLDAPURL ldap://ldaphost/o=yourorg + AuthGroupFile /usr/local/apache/passwd/groups
    + Require group GroupName
    + Require ldap-group cn=mygroup,o=yourorg +

    + +

    To take authorization a little further, the directives + <SatisfyAll> and + <SatisfyOne> allow + AND/OR logic to be applied so that the order in which authorization + is handled can be completely controled through the configuration. See + these directives for a complete example on they can be applied.

    + +
    top
    +
    +

    Beyond just authorization

    + +

    The way that authorization can be apply is now much more flexible + than just a single check against a single data store. Ordering, logic + and choosing how authorization will be done is now possible.

    + +

    Applying AND/OR logic and ordering

    +

    Controling how and in what order authorization will be applied + has been a bit of a mystery in the past. In Apache 2.2 a provider based + authentication mechanism was introduced to decouple the actual + authentication process from authorization and supporting functionality. + One of the side benefits was that authentication providers could be + configured and called in a specific order which didn't depend on the + load order of the auth module itself. This same provider based mechanism + has been brought forward into authorization as well. What this means is + that the Require directive + not only specifies which authorization methods should be used, it also + specifies the order in which they are called. Multiple autorization + methods are called in the same order in which the + Require directives appear + in the configuration.

    + +

    With the introduction of the directives + <SatisfyAll> and + <SatisfyOne>, the + configuration also has control over when the + authorization methods are called and what criteria determines when + access is granted. For example the following authorization block would + apply the logic:

    + +

    + if ((user == "John") ||
    +    ((Group == "admin") && (ldap-group <ldap-object> contains auth'ed_user) &&
    +     ((ldap-attribute dept == "sales") || + (file-group contains contains auth'ed_user))))
    + then
    +   auth_granted
    + else
    +   auth_denied
    +

    + +

    + <Directory /www/mydocs>
    +   Authname ...
    +   AuthBasicProvider ...
    +   ...
    +   Require user John
    +   <SatisfyAll>
    +    Require Group admins
    +    Require ldap-group cn=mygroup,o=foo
    +    <SatisfyOne>
    +     Require ldap-attribute dept="sales"
    +     Require file-group
    +    </SatisfyOne>
    +   </SatisfyAll>
    + </Directory>
    +

    + +

    By default all Require + directives are handled through and OR operation. In other words, if + any of the specified authorization methods succeed, then authorization + is granted. By enclosing a set of + Require directives within + a <SatisfyAll> block, + the processing switches to an AND operation which requires all authorization + methods to succeed before authorization is granted.

    + + + +

    Using 'Require' or 'Reject' for access control

    +

    Authentication by username and password is only part of the + story. Frequently you want to let people in based on something + other than who they are. Something such as where they are + coming from.

    + +

    The authorization providers + all, + env, + host and + ip let you allow or deny access based other host based + criteria such as host name or ip address of the machine requesting + a document.

    + +

    The usage of these providers is specified through the + Require and + Reject directives. + These directives register the authorization providers + that will be called during the authorization stage of the request + processing. For example:

    + +

    + Require ip address +

    + +

    where address is an IP address (or a partial IP + address) or:

    + +

    + Require host domain_name +

    + +

    where domain_name is a fully qualified domain name + (or a partial domain name); you may provide multiple addresses or + domain names, if desired.

    + +

    For example, if you have someone spamming your message + board, and you want to keep them out, you could do the + following:

    + +

    + Reject ip 205.252.46.165 +

    + +

    Visitors coming from that address will not be able to see + the content covered by this directive. If, instead, you have a + machine name, rather than an IP address, you can use that.

    + +

    + Reject host host.example.com +

    + +

    And, if you'd like to block access from an entire domain, + you can specify just part of an address or domain name:

    + +

    + <SatisfyAll>
    +   Reject ip 192.101.205
    +   Reject host cyberthugs.com moreidiots.com
    +   Reject host ke
    + </SatisfyAll> +

    + +

    Using the Reject directive + inside of a <SatisfyAll> + block, will let you be sure that you are actually restricting things to + only the group that you want to let in.

    + +

    The above example uses the + <SatisfyAll> block to make sure that all of the + Reject directives are + satisfied before granting access.

    + + + +

    Access Control backwards compatibility

    +

    One of the side effects of adopting a provider based mechanism for + authentication is that the need for the previous access control directives + Order, + Allow, + Deny and + Satisfy are no longer needed. + However to provide backwards compatibility for older configurations, these + directives have been moved to the mod_access_compat module.

    + +

    One of the problems with these directives was that the line between + authorization and access control was very fuzzy. The + Satisfy directive + tried to tie these two stages together by hooking itself into the + request processing itself. Now that these directive have been moved to the + mod_access_compat, mixing the new authorization directives + with the older access control directives becomes difficult. To address this + issue, the mod_authz_default module becomes very important and must + be loaded. The main purpose of the mod_authz_default module is + to handle any authorization requests that could not be handled by the + authorization providers. But when the older access control directives are used, + it also links access control with authorization and determines if access + should be granted based on the outcome of each stage. Therefore if the + older directives do not seem to be working properly, it might be because the + mod_authz_default module has not been loaded.

    + + +
    top

    More information

    You should also read the documentation for mod_auth_basic and mod_authz_host which contain some more information about how this all works. - mod_authn_alias can also help in simplifying certain - authentication configurations.

    + The directive <AuthnProviderAlias> + can also help in simplifying certain authentication configurations.

    And you may want to look at the Access Control howto, which discusses a number of related topics.

    diff --git a/docs/manual/howto/auth.xml.ja b/docs/manual/howto/auth.xml.ja index 1378221dfa..02acfb2603 100644 --- a/docs/manual/howto/auth.xml.ja +++ b/docs/manual/howto/auth.xml.ja @@ -1,7 +1,7 @@ - + + + +