...
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.
Meanwhile, the aspects of the Application model that pertain to agent behavior are going to largely be extracted and devolved to content settings expressible via the RequestMap (or Apache settings). This will include the ability to express both session boundaries and to customize the existence and behavior of Handlers differently for different sets of content.
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.