<li><a href="#requser">require ldap-user</a></li>
<li><a href="#reqgroup">require ldap-group</a></li>
<li><a href="#reqdn">require ldap-dn</a></li>
+ <li><a href="#reqattribute">require ldap-attribute</a></li>
</ul>
</li>
the DN fetched from the LDAP directory (or the username
passed by the client) occurs in the LDAP group.</li>
+ <li>Grant access if there is a <a href="#reqattribute">
+ <code>require ldap-attribute</code></a>
+ directive, and the attribute fetched from the LDAP directory
+ matches the given value.</li>
+
<li>otherwise, deny or decline access</li>
</ul>
<p>Apache's <code class="directive"><a href="../mod/core.html#require">Require</a></code>
directives are used during the authorization phase to ensure that
a user is allowed to access a resource. mod_authnz_ldap extends the
- authorization types with <code>ldap-user</code>, <code>ldap-dn</code>
- and <code>ldap-group</code>. Other authorization types may also be
- used but may require that additional authorization modules be loaded.</p>
+ authorization types with <code>ldap-user</code>, <code>ldap-dn</code>,
+ <code>ldap-group</code> and <code>ldap-attribute</code>. Other
+ authorization types may also be used but may require that additional
+ authorization modules be loaded.</p>
<h3><a name="reqvaliduser" id="reqvaliduser">require valid-user</a></h3>
<p>Behavior of this directive is modified by the <code class="directive"><a href="#authldapcomparednonserver">AuthLDAPCompareDNOnServer</a></code>
directive.</p>
+
+<h3><a name="reqattribute" id="reqattribute">require ldap-attribute</a></h3>
+
+ <p>The <code>require ldap-attribute</code> directive allows the
+ administrator to grant access based on attributes of the authenticated
+ user in the LDAP directory. If the attribute in the directory
+ matches the value given in the configuration, access is granted.</p>
+
+ <p>The following directive would grant access to anyone with
+ the attribute employeeType = active</p>
+
+ <div class="example"><p><code>require ldap-attribute employeeType=active</code></p></div>
+
+ <p>Multiple attribute/value pairs can be specified on the same line
+ separated by spaces or they can be specified in multiple
+ <code>require ldap-attribute</code> directives. The effect of listing
+ multiple attribute/values pairs is an OR operation. Access will be
+ granted if any of the listed attribute values match the value of the
+ corresponding attribute in the user object. If the value of the
+ attribute contains a space, only the value must be within double quotes.</p>
+
+ <p>The following directive would grant access to anyone with
+ the city attribute equal to "San Jose" or status equal to "Active"</p>
+
+ <div class="example"><p><code>require ldap-attribute city="San Jose" status=active</code></p></div>
+
+
+
</div><div class="top"><a href="#page-header"><img alt="top" src="../images/up.gif" /></a></div>
<div class="section">
<h2><a name="examples" id="examples">Examples</a></h2>
dialog (i.e. when you use a single Pass Phrase for all N Private Key files
this Pass Phrase is queried only once).</p></li>
+<li><code>|/path/to/program [args...]</code>
+
+ <p>This mode allows an external program to be used which acts as a
+ pipe to a particular input device; the program is sent the standard
+ prompt text used for the <code>builtin</code> mode on
+ <code>stdin</code>, and is expected to write password strings on
+ <code>stdout</code>. If several passwords are needed (or an
+ incorrect password is entered), additional prompt text will be
+ written subsequent to the first password being returned, and more
+ passwords must then be written back.</p></li>
+
<li><code>exec:/path/to/program</code>
<p>
Here an external program is configured which is called at startup for each
<code>www.example.org</code> (from our <a href="#name">name-based</a> example, setup 2) should get its own IP
address. To avoid problems with name servers or proxies who cached the
old IP address for the name-based vhost we want to provide both
- variants during a migration phase.<br />
+ variants during a migration phase.</p>
+
+ <p>
The solution is easy, because we can simply add the new IP address
(<code>172.20.30.50</code>) to the <code>VirtualHost</code>
directive.</p>
<code>http://www.sub1.domain.tld/</code> is only
served from the sub1-vhost if the client sent a correct
<code>Host:</code> header. If no <code>Host:</code> header is sent the
- client gets the information page from the primary host.<br />
- Please note that there is one oddity: A request to
+ client gets the information page from the primary host.</p>
+
+ <p>Please note that there is one oddity: A request to
<code>http://www.sub2.domain.tld/sub1/</code> is also served from the
- sub1-vhost if the client sent no <code>Host:</code> header.<br />
- The <code class="directive"><a href="../mod/mod_rewrite.html#rewriterule">RewriteRule</a></code> directives
+ sub1-vhost if the client sent no <code>Host:</code> header.</p>
+
+ <p>The <code class="directive"><a href="../mod/mod_rewrite.html#rewriterule">RewriteRule</a></code> directives
are used to make sure that a client which sent a correct
<code>Host:</code> header can use both URL variants, <em>i.e.</em>,
with or without URL prefix.</p>
projects / apache / commitdiff