Format: Native Spring
The IdP includes a number of administrative functions, and a simple access control facility has been provided to limit access without requiring additional web server configuration. While Apache is typically pretty simple to use for this purpose, Java containers tend to be much less simple to configure in this manner and many if not most deployments don't use Apache.
This facility supports the creation of named policies that implement particular access control rules, so that the policies can be shared and attached by name to particular services. The original policy implementation supplied relies on IP range controls. V3.3 introduces an adapter allowing use of arbitrary Predicate conditions to be applied, including scripts or Spring Expressions.
As a reloadable service, you can modify named policies at runtime and as long as the policy names don't change, the rule changes will take effect without restarting the IdP.
Creating and Applying Rules
The access-control.xml file contains a bean called shibboleth.AccessControlPolicies that is a map of policy names to beans implementing particular access control strategies. You can follow the example provided to alter the existing policy or create your own.
As of V3.3, the policies defined here are primarily applied to administrative functions via the admin.xml file.
Beans defined in access-control.xml and related system files follow:
|shibboleth.AccessControlPolicies||Map<String,AccessControl>||Map of policy names to access control objects/rules|
|shibboleth.IPRangeAccessControl||IPRangeAccessControl||Parent bean for creating IP range checking access control rules|
|shibboleth.PredicateAccessControl 3.3||PredicateAccessControl||Parent bean for creating Predicate-based access control rules|
The only comparable V2 feature was to put acceptable IP ranges for the status handler directly into web.xml. This feature replaces that approach.