...
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.
Tip | |
---|---|
title | Location Blocks Take Precedence.htaccess directives are able to override |
Table of Contents |
---|
General Syntax
The general syntax of a Require
rule is:
...
The SP supports the following rule "types" (the type is the first parameter of the command):
Rule | Apache Version | Details |
---|---|---|
shibboleth | This is a special "dummy" rule that allows |
Require
command a Require command to be inserted to satisfy Apache's requirements when using |
AuthType
commandthe 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 | 2.4 and Later OR ShibCompatWith24 | A rule that requires an authenticated session, but nothing else. No information of any kind about the user is required in order to satisfy this rule and it should never be used in the absence of additional application logic to perform authorization. This is equivalent |
to require valid-user |
ShibCompatValidUser
is Off
when ShibCompatValidUser is Off | ||
shib-user | 2.4 and Later OR ShibCompatWith24 | A rule based on the REMOTE_USER value established for the request. The remaining parameters are the values to compare against. Regular expression and negation modifiers are supported (see below). |
group | 2.2 and Earlier | A rule to check membership of the REMOTE_USER value established for the request against a group membership file designated with the AuthGroupFile command. The remaining parameters are the names of groups to check membership against. |
authnContextClassRef | A rule based on the SAML authentication context class or method asserted by the IdP. The remaining parameters are the values to compare against. | |
authnContextDeclRef | A rule based on the SAML authentication context declaration asserted by the IdP. The remaining parameters are the values to compare against. | |
shib-plugin | 2.4 and Later OR ShibCompatWith24 | Enables the use of XML Access Control rules for access control. The single parameter is the path to an access control configuration file. The plug-in is loaded on every request, which allows on-the-fly changes of access control rules (though is less efficient if large rulesets are used). This is equivalent to the |
ShibAccessControl
option older ShibAccessControl option and can be enabled for use with older Apache versions using |
ShibCompatWith24
optionthe ShibCompatWith24 option. | ||
shib-attr | 2.4 and Later OR ShibCompatWith24 | The Apache 2.4 authorization API does not allow for "extensible" rule types within a single module, so to accomodate rules based on attributes, a new rule type is used. The first parameter to the rule specifies the attribute ID to check, and the rest of the parameters are used as values to check for. This rule type can be enabled for use with older Apache versions using |
ShibCompatWith24
optionthe ShibCompatWith24 option. Note that for literal comparisons, the case sensitivity of the match is dependent on |
caseSensitive
property the caseSensitive property applied when the attribute is decoded |
Rule Modifiers
Two 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
Modified | Details |
---|---|
~ (tilde) | The tilde modifier causes the rest of the parameters to be interpreted as regular expressions rather than literal values. The |
! (bang) | The bang modifier inverts the rule such that a non-match satisfies the rule. This does not apply to rules based on arbitrary attributes (the ones identified by an arbitrary string). |
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).
...
To control this behavior, the AuthzShibAuthoritative
command is supplied. The following matrix describes how the options interact when an unrecogized rule is found:
AuthzShibAuthoritative On | AuthzShibAuthoritative Off | |
---|---|---|
ShibRequireAll On | Access Denied | Decision Left to Other Modules |
ShibRequireAll Off | Ignored | Ignored |
Recommended Practices for Compatibility
The following are suggested steps to take to avoid work in the future:
Prior to Apache 2.4, turn on
ShibCompatWith24
to enable the newer versions of various rules. Make sure you have no existing rules by those names referring to custom attributes.Avoid Shibboleth-style use of the
valid-user
anduser
rules, and replace them withshib-session
andshib-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 onShibCompatValidUser
.
The soonest changes would be made to remove deprecated options is in a V4.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 of this is the best option.
Examples
Requiring students from particular domains
Code Block | ||||
---|---|---|---|---|
| ||||
# Direct comparison Require shib-attr affiliation student@osu.edu student@psu.edu # Using an expression Require shib-attr affiliation ~ ^student@(osu|psu)\.edu$ |
Blacklisting users from particular domains
Code Block | ||||
---|---|---|---|---|
| ||||
Require shib-user ! ~ ^.+@(osu|psu)\.edu$ |
...