Page Comparison

...

Outbound SAML Artifact Binding Support

This does NOT refer to supporting IdPs that use the SAML Artifact binding to issue responses (the callback model that is similar to how CAS and OpenID typically function) but to the virtually unused capability to issue SAML requests to an IdP by sending artifacts and relying on IdP callback into the SP to resolve the message. This feature was more of an “accident” of the SAML design than a real feature anyone needed or used and we won’t be supporting it.

Workaround

None. The normal request process relies on redirects and so there is no obvious reason to use this feature, and most non-Shibboleth IdPs don’t support it anyway.

Inbound SOAP Single Logout Support

The SP supports SOAP-based logout inbound, but this is difficult to successfully implement given the common (bordering on universal) use of application sessions independent from the SP. Given the complexity of supporting SOAP inbound, it is planned to remove the feature in favor of front-channel logout support only. This is not a totally firm decision, but would be a helpful reduction in code.

Workaround

Switch to front-channel logout.

SAML-Specific Naming of Features

A number of features/settings will probably get renamed to be more portable and less SAML-specific. This will probably include anything based on the “entityID” term, anything based on SAML-specific fields such as “AuthnContextClassRef”, etc. In most cases, they will simply have more generic names replacing them. We’ll make some case by case determinations about removal vs. deprecation.

Workaround

Unless noted otherwise, these will be naming changes in general, not actual removal of features. These are typically configuration settings, and not likely to impact application code.

SAML AuthnContextDeclRef Support

The old session objects contained a SAML 2.0 AuthnContextDeclRef if one was used in place of a class reference in the assertion. DeclRefs are virtually unused and are SAML-specific and hard to “abstract” into a more general representation. This also extends to removal of the dedicated authorization rule support in both XML syntax and Apache.

Workaround

The “claims/attributes” mapping features should be substantial enough such that the hub can extract a DeclRef into an attribute that could be mapped to any desired name (such as the old name used in the standard exported variable set). The authorization rules can be adjusted to check for an attribute/value.

Assertion Export

This is regarding the feature outlined in AssertionExport. It’s a lot of code to implement for a very small number of use cases that are probably fairly historical for the most part since using SAML assertions for anything but SSO these days has been replaced by OAuth. It was quite complex for an application to use as well, so is planned for removal.

Workaround

One of the use cases for this was sometimes advanced extraction of custom data from assertions. That will be much simpler to implement in Java in the hub to populate attributes from the custom data.

The more “traditional” use case involving the use of signed assertions as a token for other systems to consume is not really a use case we want to support but in principle it should be possible to use the hub to turn an entire assertion into a base64-encoded attribute as part of a session. That may not fit in a header (which is why we did the crazy callback thing originally) but it might be more straightforward in V4 to expose a similar callback feature that could pull any attribute out of a session, which is still much cleaner than the weird “export the count and callback URLs” machinery from V3. Input on any extant use of this feature may inform our decisions on that.

Application Overrides

It's difficult at this stage to fully describe without preliminary configuration examples, but the plan is to eliminate the concept of an “Application” from the agent while retaining the concept in the hub. There’s material about this design plan in the wiki elsewhere, but essentially the aspects of the Application model that pertain to SSO protocols (i.e., SAML) and to attribute handling are going to be possible to manage in the hub in a similar way. Agent configuration will continue to be responsible for mapping URLs to the associated application, but these application designations will only be “real” in the hub, so it’s a way to connect URL space to hub configuration indirectly. Because the hub is in Java, the application configurations will be reloadable (and possible to externalize to some extent) in much the same way as now.

...

Essentially what was originally handled inside the SP will be divided into two sets, and the agent aspects simplified as much as possible to reduce the complexity for application deployers and moved to hub deployers.

Workaround

None per se, but it will become more important than ever to get people to stop misusing overrides for many use cases already addressed such as overriding an SP’s entityID based on content. That will be handled, but differently, by allowing hubs to compute the setting in dynamic ways in Java/JavaScript, much as the IdP supports. This will also allow plugging a hostname into an entityID pattern much as now. Bottom line, things that don’t require an override now will be even more awkward to use overrides to address, so it will be important to transition off of them for those cases.

SameSite Fallback for Broken Clients

The current SP includes a lot of code designed to support “fallback” such that if SameSite is applied to cookies, it creates specially named fallback cookies for broken clients that interpret SameSite incorrectly. These clients are all out of date, out of support, and long since superseded by newer versions, and most truly old clients properly ignored the setting anyway. We cannot justify keeping dozens of lines of convoluted code to keep supporting these clients.

Workaround

Update outdated clients.

Error Handling Templates and Template Use in General

The SP’s support of a primitive HTML templating language will be removed, and error handling in general will be very simplified and stripped back to rely on a combination of native web server error code use (typically allowing native support for custom error pages) and some form of the existing feature to redirect to a specified URL with parameters for error handling. This will be examined for safety in the face of injection attacks, so it’s likely some aspects of this will be scaled back.

Workaround

Our impression is that the vast majority deployments have not used these templates even a little, with logos absent, error text unchanged, and even contact links left invalid, which looks embarassing and reflects badly on our software. Using native error handling will typically mask most of this from users, and logs continue to be the only real source of resolution information anyway. Existing usage of the redirect-based error handling feature seems relatively uncommon, but may require some minor changes.

Attribute Templating and Transformation

This refers to the TransformAttributeResolver and TemplateAttributeResolverfeatures. These features are (somewhat obviously I imagine) being subsumed by the use of the hub to apply the IdP’s existing attribute manipulation support to the inputs rather than continuing to allow for that manipulation in the agent.

Workaround

Use the hub to transform data as required before it gets returned to agents.