V5Changes

Tracking any compatibility changes during development for the release notes.

Deprecated Beans/Properties

  • Liberty.SSOS

  • Liberty.SSOS.MDDriven

  • shibboleth.SameSiteCookieFilter (ref’d in web.xml)

  • shibboleth.ResponseHeaderFilter (ref’d in web.xml)

Removed Beans/Properties

  • shibboleth.HttpServletRequest (use Supplier instead)

  • shibboleth.HttpServletRespoonse (user Supplier instead)

  • shibboleth.OutgoingIDWSFSSOSBindings

  • shibboleth.Encoders.IDWSFSOAPEncoder

  • shibboleth.Binding.LibertySOAP

  • shibboleth.Conditions.IssuingDelegatedAssertion

  • shibboleth.Conditions.AllowedSAMLPresenters

  • shibboleth.authn.Password.PrincipalOverride

  • shibboleth.authn.Password.ExtendedFlows

  • shibboleth.authn.Password.ExtendedFlowParameters

  • idp.service.attribute.resolver.suppressDisplayInfo

New Beans/Properties

  • idp.cookie.bufferingCondition

  • idp.encoding.forceUTF8

  • idp.logging.MDC.enabled

  • idp.logging.MDC.createSession

User Visible

  • Removed V2 scripted attribute compatibility classes

  • Added methods to SPSession interface for logout enhancements dating to V4.2

  • Deprecated and ignored profileContextRef (sp?) XML attribute in resolver and filter schemas and parsers

  • LDAPDataConntector. We now use LDAPTIVEV2 so

  • All DataConnectors. The following attributes can no longer be supplied. For the first four, since 4.3 all data connectors can have appropriate bean injected using the xyzRef="BeanId" paradigm.

    • springResources

    • springResourcesRef

    • factoryPostProcessorsRef

    • postProcessorsRef

    • exportAllAttributes (no replacement)

  • All Data Connectors and all Attribute definitions profileContextStrategyRef="beanID" can no longer be supplied

  • EntityRoleWhiteList Metadata filter type has been removed

  • profileContextStrategyRef="BeanID" removed from all Attribute Definitions and Data Connectors

  • ignoreCase="bool" in <SourceValue/> (part of a Mapped Attribute Definition) has been removed

  • Attribute failFast removed the the StoredID Data Connector

  • Attribute readOnly removed the the RDBMS Data Connector

  • Attribute ignoreCase remove from all Attribute Filter Elements

  • Attribute contextStrategyRef removed from the Predicate Policy Rule

  • MappedAttributeInMetadata Policy no longer supported

Programmer Visible (-api changes)

Removed various APIs related to SAML delegation

Removed profileRequestContextLookupStrategy on various resolver and filter plugins

IdPAttributes can no longer display information

IdPAttribute#setValues() takes a List not a Collection (non-list deprecated since at least 4.1)

Removal of joda-time and a few deprecated APIs that supported it. Major impact is use of DateTime for external authentication time signaling, and using the joda-time formatter string/class wiring up a DateAttributePredicate, usually part of expiring-password config.

We only ever inject HttpServletRequest or HttpServletResponse into an object if it is known to have a short life (which means exactly one place - org.opensaml.saml.saml2.profile.impl.ValidateAssertions.AssertionValidationInput. In all other places we inject a java.util.function.Supplier. Two new beans are set in global-system which return the object directly from the TLS.

net.shibboleth.shared.spring.service.ClassBasedServiceStrategy can now handle arbitrary objects. This means that the zero parameter constructor no longer exists.

Migration of net.shibboleth.utilities.java.support → net.shibboleth.shared

  • codec

    • Definitely used a fair bit, but the StringDigester can be rewired via Spring and the HTMLEncoder was left stubbed for compatibility. The others should be mostly used in code only, but we may end up wanting stubs for Base32/Base64.

  • collection

    • Mostly these are our interfaces and APIs, but Pair is an exception that has a parent bean but likely it came later than 3.0 so might be an issue. Discussed possibly migrating off of Pair to Java Records.

  • component

    • Our APIs by and large.

  • net

    • Impacts a few APIs some might use in scripts to do servlet-y things, but should be rare. IPRange in particular tends to be used with String conversions via Spring.

  • httpclient

    • Used in some APIs but not likely by many deployers. One exception is the HttpClientSupport class which gets used in scripts to process response bodies, eg. in the HTTP data connector. To maintain compatibility, a stub with warnings was left behind.

  • logic

    • Lots of classes used mostly in Spring wiring (rewrites added to IdP), but left behind a couple of stubs for PredicateSupport and FunctionSupport. Removed our Predicate bridge interface used during the Java 8 transition.

  • primitive

    • Pretty much only StringSupport matters much here, a stub was left for that.

  • resolver

    • Our APIs used by a lot of our code but hopefully not by deployers much.

  • resource

    • One interface, our non-Spring version of Resource, really just used in APIs and not as a class itself.

  • services

    • ServiceableComponent now extends AutoCloseable. Any code using ServiceableComponent should be changed to exploit this

    • The implementation details of ServiceableComponent management (pin/unpin/unload) have been removed from that interface. As a result of this, any code implementing ServiceableComponent but wanting to exploit ReloadableSpringService must extend AbstractServiceableComponent.

  • scripting

    • Used by our higher level classes.

  • security

    • Command line tool changes but those are captured in shell files we supply. The AccessControl interfaces move but I don’t expect deployers would have directly interacted with that service as an API. Various beans move but they’re system-defined in almost all cases. Biggest API ripple is the IdentifierGenerationStrategy stuff, but that’s unlikely to affect anybody but us and probably needs more work given the use of impl classes all over the code base.

  • xml

    • Moved BasicParserPool and an errorhandler class into an impl subpackage. Lots of Java code will have used the various XSupport classes and likely depend on the ParserPool and exception classes, but I do not expect deployer impact of much significance.