When used with Apache, the SP includes an Access Control plugin implemented on top of the Apache Require
authorization command. The placement rules for this command are dictated by Apache, and include its <Directory>
, <File>
, and <Location>
blocks, as well as .htaccess
files. By default, any place you can apply the Require
command will trigger the Access Control implementation supplied with the SP's Apache module.
Make sure that any user will have already established a session, or require a session for the same path, or any access attempt will result in a 403.
.htaccess directives are able to override |
The general syntax of a Require
rule is:
Require rule-type value1 value2 |
Some of the rule types support a regular expression mode:
Require rule ~ exp1 exp2 |
The SP supports the following rule "types" (the type is the first parameter of the command):
shibboleth
Require
command to be inserted to satisfy Apache's requirements when using the AuthType
command. It takes no parameters and has no effect other than to ensure that the module sees and processes requests. It does not restrict access based on whether a user is logged in, and is therefore commonly used with the lazy session feature.shib-session
(Shibboleth V2.5.2 and Later) (Apache 2.4 and Later OR ShibCompatWith24
)
valid-user
in older releases, or when ShibCompatValidUser
is Off
.valid-user
(Deprecated)ShibCompatValidUser
is Off
(the default), this is equivalent to the shib-session
rule above. When the ShibCompatValidUser
option is enabled, this rule is implemented compatibly with the rule implemented by Apache itself and requires a non-null REMOTE_USER value be set for the request. This restores the ability to deploy Shibboleth along with other modules and rules. A future version of the SP may remove the "special" definition and such rules should be changed to rely on shib-session
.shib-user
(Shibboleth V2.5.2 and Later) (Apache 2.4 and Later OR ShibCompatWith24
)
user
(Use of ~/! Modifiers Deprecated)
ShibCompatValidUser
is Off
(the default), this is equivalent to the shib-user
rule above. When the ShibCompatValidUser
option is enabled, this rule is implemented compatibly with the rule implemented by Apache itself and does only standard string matching against REMOTE_USER. This restores the ability to deploy Shibboleth along with other modules and rules. A future version of the SP may remove the "special" definition that supports modifiers and such rules should be changed to rely on shib-user
.group
(Apache 2.2 and Earlier)AuthGroupFile
command. The remaining parameters are the names of groups to check membership against. Starting with Apache 2.4, support for this option is left up to other "out of the box" Apache module support for group-based rules, rather than reimplemented by the SP.authnContextClassRef
authnContextDeclRef
shib-plugin
(Apache 2.4 and Later OR ShibCompatWith24
)ShibAccessControl
option and can be enabled for use with older Apache versions using the ShibCompatWith24
option.shib-attr
(Apache 2.4 and Later OR ShibCompatWith24
)ShibCompatWith24
option. Note that for literal comparisons, the case sensitivity of the match is dependent on the caseSensitive
property applied when the attribute is decoded.shib-attr
.A pair of rule modifiers are supported to affect the processing of the rule types that accept parameters (all but the first two above). Modifiers are placed after the rule type but before any comparison values.
group
rule does not support this modifier.The two modifiers can be combined, so as to enforce a regular expression that must NOT match. When using both modifiers, be sure to separate them with a space (see examples).
As of Apache V2.4, authorization rules are designed to be handled by specific modules that register for them. With this change, the notion of combining rules from different modules is a first-order concept using a feature called authorization containers. This renders the commands described below obsolete and they are no longer supported.
Prior to Apache V2.4. the server functions by allowing access if any rule is satisfied. This allows rules recognized by different modules to appear, since modules can ignore rules they don't understand and simply grant access on their own, but limits the kinds of combinations possible.
The SP module includes a ShibRequireAll
command that changes this semantic and requires that all rules present be satisfied before granting access. This is straightforward as long as all the rules are known to the SP module, but becomes complex if other modules are involved.
To control this behavior, the AuthzShibAuthoritative
command is supplied. The following matrix describes how the options interact when an unrecogized rule is found:
|
|
|
---|---|---|
| Access Denied | Decision Left to Other Modules |
| Ignored | Ignored |
The following are suggested steps to take to avoid work in the future:
ShibCompatWith24
to enable the newer versions of various rules. Make sure you have no existing rules by those names referring to custom attributes.valid-user
and user
rules, and replace them with shib-session
and shib-user
respectively (if needed). Of course, if all you need is the existing Apache semantics, feel free to use them. On Apache 2.4, turn on ShibCompatValidUser
.The soonest changes would be made to remove deprecated options is in a V3.0 release of the SP, and there are no current plans for that. However the various combinations and issues are quite complex due to the software's age, so avoiding all this is the best option.
# Direct comparison Require shib-attr affiliation student@osu.edu student@psu.edu # Using an expression Require shib-attr affiliation ~ ^student@(osu|psu)\.edu$ |
Require shib-user ! ~ ^.+@(osu|psu)\.edu$ |