Acceptable Use of ApplicationOverrides in SPv3 and SPv4

[Scott Cantor]

> On Oct 30, 2026, at 3:22 PM, Bryan K. Walton via users <users at shibboleth.net> wrote:
> 
> We are an SP that works with about 450 different IdPs. As such, we have
> to make use of a lot of ApplicationOverride sections.  I know that the
> Shibboleth project thinks this isn't a very good practice, but each of
> these IdPs have different attribute mappings, metadata urls,
> redirectAllow urls, and session/lifetime timeout settings.

A lot of that doesn't require overrides except certainly the session policies, which don't as a rule usually depend on the IdP (*) and don't need overrides in V4, as they can be controlled now based on URL. A lot of settings that used to be application or session level are content-based now to reduce even further the need for what used to be messy to handle.

Sessions can even be forcibly partitioned in V4 using cookie name settings without resorting to overrides, essentially artificially controlling what cookies get searched based on the request.

(*) IdPs can also override session length (though not timeouts) in the way SAML defines, an SP needn't do it for them explicitly, if it's a requirement that really is coming from that end.

> Based upon the Shibboleth SP documentation, we are now experimenting
> with using a setting in the Apache virtualhosts to move
> entityID out of the Application Override:

That is still permitted in V4. Using scripting or Java code in the Hub to compute it based on the request is a way to offload it from the Agent too, but we don't intend to disallow some of the SAML awareness in the Agent, so the entityID or issuer can still be "forced" from that end using that sort of command.

A "one SP" situation where the Hub is there because it has to be, rather than to help offload skill sets and scale deployments across an enterprise, is a different paradigm and some of the "avoid contamination of SAML into Agent" goals aren't as critical.

> It seems like most of our reasons are valid in version 3 and most of these will
> still be around in version 4, if my reading of the new documentation is
> correct.  Please correct me if I'm wrong.

"Valid" and "a good idea" aren't the same thing. Valid just means "if you want to do this thing, that may or may not be a good idea, this is the only way".

Ultimately, it's not about good or bad. It's about whether one can support and maintain the system and particularly if one can do so without support one isn't paying for. Historically, the answer has been "no", and that is the main reason they're discouraged, but that's also why they weren't just outright removed from the design, though they are even more isolated now.

And V4 is simply so radically different in configuration style that there just isn't a comparison. There are many more ways to avoid them there because of the expanded capabilities of a Spring-based configuration and extensibility model that can dynamically adjust behavior or conditionalize rules and settings based on, e.g. the issuer of the token.

I couldn't even specifically say I know what an override would still be useful for now, I left them mainly as an escape hatch in case something arises.

> However, because we work with so many IdPs, we also make heavy use of
> the LowerCase AttributeResolver plugins to lowercase attributes that
> come in to us in an inconsistent case format.  We don't control any of
> these IdPs.
> 
> Why is this feature being removed?

It isn't. Quoting the release notes (draft obviously):

"The Hub is expected to provide any manipulation required via traditional Attribute Resolver features already included with the IdP software. The features are therefore not removed exactly, merely relocated or replaced with the general scripting and extensibility features of the Hub. However, for visibility, warnings have been added to the old version that indicate their removal."

It's not gone, it's simply a completely different approach that is subsumed under a vastly more capable mechanism that is familiar to anybody that knows the IdP but quite new otherwise (the attribute resolver service).

Anything the SP could do before in the attribute space is easily within the capability of the resolver service running in the Hub.

What is confusing about the Hub concept is not the Hub itself but the fact that the IdP software out of necessity now still ships as an IdP. If the IdP functions were also plugins now so that the actual "thing" being installed isn't an IdP or SP/Hub but just a "plugin shell that hosts services and web flows", it wouldn't be as strange, but that's ultimately what the IdP is now. It just comes pre-built with the IdP "stuff" inside it because it would take more work and more changes to pull all of that out. CAS certainly should be a plugin by now, we just have to find the time for it.

The metadata resolver and the attribute resolver, filter, registry services were all things the old SP had in more limited form, and they still exist now because the IdP that the Hub runs inside already provides them in more mature, maintainable, and advanced forms.

The point of "deprecating" things isn't always to say they're gone, but to say "this is to radically different that you need to be aware of its use". In this case, the intent is also to say "if you're a typical SP operator now, you aren't the one to be doing that step anymore, your Hub operator will handle it".

When somebody is both, that is a different (and frankly low probability) scenario, so the message is slightly messy.

I think the fundamental thing to understand is that a highly federated SP today (the minority to be clear) now consists of an Agent that needs to care about virtually none of that, and a Hub that handles all of it. The Hub is not a proxy, but it serves a similar function in that kind of scenario in "finessing all the details and complexities" down for the Agent to consume.

-- Scott