Page Comparison

The IdP includes support for login methods that rely on another IdP to actually authenticate the subject, with the results used to produce the eventual responses to the proxying IdP's own services. This is a common feature of most other SAML software but is newer to Shibboleth.

There are a number of different low-level features included to better support this use case as well as to ensure that the default behavior aligns to the SAML 2.0 standard, which includes a number of precise rules for proxying and for limiting and even preventing proxying behavior.

As a rule, the IdP doesn't explicitly assume that a given login flow is or isn't a form of proxy authentication. It defaults to certain assumptions but relies on the deployer to tell it when proxying is involved by adjusting properties (in V4.1 via authn/authn.properties), or by editing XML (in V4.0 on the beans defined in authn//general-authn.xml).

The topic of Proxying goes a fair bit beyond authentication considerations, but some of the considerations are summarized here. The rest are mostly in the areas of SubjectCanonicalizationConfiguration, AttributeResolverConfiguration, and AttributeFilterConfiguration.

IdP Discovery

When proxying, the IdP now supports calling out to a standardized discovery service.

In V4.0, or upgraded systems that continue to rely on the legacy conf/authn/general-authn.xml file to configure login flow behavior, discovery can be enabled for login flows designed to allow for proxying by enabling the discoveryRequired property on the login flow descriptor bean and configuring the location of the discovery service via conf/authn/discovery-config.xml

In V4.1+, discovery can be enabled for login flows designed to allow for proxying by enabling the corresponding flow-specific "discoveryRequired" property in conf/authn/authn.properties and setting the idp.authn.discoveryURL property to the location of the discovery service.

A successful discovery result will make the value returned available via AuthenticationContext.getAuthenticatingAuthority() and will be automatically used by login flows designed to take advantage of it.

Scoping

Another point of policy is honoring the <saml2:Scoping> element if included by an SP in its request. This allows an SP to disallow proxying, or control the length of the proxy chain. The IdP doesn't normally enforce this for most login flows because it assumes that it isn't proxying. Out of the box, only the new SAML login flow is designated to enforce this control, but the proxyScopingEnforced property can be enabled for a login flow when applicable. Of course, this also means you can bypass the control when really proxying by turning it off. Doing so is a standards violation and a generally slimy thing to do.

Forced Authentication

Another assumption the system makes is that a request asking for forced authentication (the ForceAuthn flag in SAML or similar features in other protocols) should be relayed to a proxied IdP. This is the default, but can be overridden on a per-IdP basis via Profile Configuration by explicitly turning off the setting.

Authentication Type Mapping

Finally, a potentially complex issue arises when it comes to passing SAML <AuthnContextClassRef> values and comparable constructs in other protocols back and forth across the proxy boundary. In many cases, the values used on the inside and outside are different. The IdP provides pluggable hooks for this, but defaults to allowing the use of pre-defined map beans to express the relationships in both directions. The beans are defined in conf/authn/authn-comparison.xml (if you upgraded, compare your copy to the distributed version to see the new settings):

• shibboleth.PrincipalProxyRequestMappings

  • These are rules for turning the values that apply to, or are contained in, SP requests into new values to express in a request issued to a proxied IdP.

• shibboleth.PrincipalProxyResponseMappings

  • These are rules for turning the values that appear in proxied IdP responses into new values to capture in the resulting subject's authentication record and subsequently potentially used in responses to SPs.

In both cases:

• Omitting an explicit mapping rule will result in the value being copied unmodified.

• A key with an empty list as a value will be suppressed and not included at all.

• Explicit mappings will turn an instance of the key into one or more values.

This is hopefully sufficient for most basic proxying scenarios, and is adapatable to all supported protocols now and in the future.

Note that this does not currently extend to the practice of expressing this information using SAML Attributes. This overlaps with the function of the <AuthnContext> element and does not have any supporting guidance in the standard that would indicate it's an appropriate thing to do, as Attributes are about the Subject of an Assertion, not about the act of authentication that led to one.