One of the following child elements can be used to attach an access control policy to the resource. This is a violation of the axiom that the SP doesn't do access control, but it's really just a call-out that has some predefined plugins you can use as examples to create more.matching requests:
<htaccess>
- Enables native Apache
.htaccess
support during the Apache's authorization phase. This is automatic and implicit for the "Native" request mapperimplicitly plugged in for theNative
RequestMapper, but can be enabled by hand if the "XML" request mapper is theXML
RequestMapper is used. Note that this will fail for non-Apache servers.
- Enables native Apache
<AccessControlProvider>
Attaches a custom access control
policy supportedimplementation provided by a plugin
.
<AccessControl>
Attaches an access control policy using
the samplethe XML-based plugin provided with the SP. This is
justa short-hand for embedding the policy in the element above, if you want the policy inside the
sameRequestMapper's configuration file anyway.
If no element is included (or inherited or implicitly enabled), any access control is left to the resource itself and the SP simply passes its session information along.
If an error occurs when processing this element, a dummy policy to deny access is installed to prevent accidental exposure.