...
The V3 SP installer no longer provides the option to install the old-style ISAPI filter, but on a machine with V2 previously installed, the old isapi_shib.dll plugin is upgraded to the latest build and left in place. This is deprecated and unsupported, but will continue for the life of this major version.
| Tip |
|---|
No 32-bit shibd needed on 64-bit OSThe 32-bit web server modules can function with a 64-bit shibd service, so there is no need to install a 32-bit shibd to handle 32-bit app pools. |
...
There should be no immediate need to make any changes to the shibboleth2.xml file, nor even to restart shibd, but it is best to reboot at this stage (or if the configuration ever seems to "stick"). Retest, bearing in mind that an unchanged configuration will not be setting headers but will be setting variables.
If the ISAPI module is still configured the following tell-tales will indicate this:
The event viewer ("Windows Logs\Application") may show a warning.
An attempt to access a protected resource will return a failure (status 500) and the native log output will have the following line:
ERROR Shibboleth.NATIVE [<pid>] native_shib: Shibboleth handler invoked at an unconfigured location.This indicates that configuration for the ISAPI filter is still active somewhere.
Configuration and Behavioral Changes
The IIS7 plugin is fully defined in the <ISAPI> documentation; the following changes should be noted:
If a
<Site>element is not specified for a site which uses the plugin, then the module will ignore requests to that site, as with the old plugin.When the
<Site>element is specified, the following new settings can be provided:useVariables=boolean(default true) controls whether attributes are passed to the application as Server Variables.useHeaders=boolean(default false) controls whether attributes are passed to the application as HTTP Headers. This setting should be avoided but is present to provide a level of compatibility with applications developed against the old isapi_shib plugin. You should move aggressively to fix this.
REMOTE_USER will (usually) be populated in the manner one expects and that is familiar to the use of Shibboleth on Apache. This was not possible with the old plugin, which populated a weird and dangerous header (HTTP_REMOTE_USER) as a workaround. The new module does not populate that header regardless of the settings used, so this may impact applications immediately.
Additionally, a new element
<Roles>may be specified. This configures the roles that can be used in native Roles Based Authorization.
...