Background
The SP configuration is a pretty severe case of scope creep, with settings being added constantly over many years of development and only partly having a consistent sense of design around where they ended up. This was partly due to the SP implementing a very generic DOM-based configuration API allowing settings to be added more or less all the time without major API changes and being accessed by string name and not via concrete APIs. This has a lot of pros and cons but the lack of rigor makes the overall system worse over time, which is where it’s ended up. It’s a mess of different buckets of settings and not all of them are likely in the best places.
...
As a starting point, progress means going through all of the settings and putting them into appropriate categories or identifying them as overtaken by changes or in light of the new design. That will inform the API design for now.
Content Settings
The term “content settings” is used in the old design to reflect anything meant to apply at a content level, i.e., per request down to the path, file, etc. More or less anything that fit into the Apache command model. The trick with these settings is that anything plausibly wanting to be content-driven almost has to be left here because to do anything else would couple the hub configuration with the content model too tightly. In other words, the last thing you ever want is to have to centrally change a Spring config because a path changes. That’s just out of the question.
...
Name | Type | Notes |
|---|---|---|
applicationId | string | This tied the requests back to the Application layer and will continue to be needed. Since Applications are now contained and scoped by Agents, we should not need to force any new unique-ing convention for this. |
authType | string | This is really meant to be Apache’s AuthType concept, but I don’t think it fits into the RequestMapper all that well and it ultimately become more of an on/off switch. Removing it may be more hassle than it’s worth though. |
requireSession | boolean | The big Kahuna, activates active session protection for content, obviously staying. |
requireSessionWith | string | This was a special case of the previous that tied into how to issue requests for a login. Keeping it is plausible, but I would ideally prefer to wait on that pending a review of the SessionInitiator settings and where they really fit. Could be that the need is more to package up those settings as a stand-alone object/API and this would maybe reference those objects, but it may also be just time to dump the idea and move solely to the use of protocol-specific settings that ultimately overtook this concept. |
requireLogoutWith | URI | Hook for triggering content-specific logout code after the SP logout completes. This isn’t inherently non-functional in a world where the IdP ends up with control since it should be runnable in an IdP-hosted frame (aside from the TPC issues). |
exportAssertion | boolean | This was a SAML-specific as a hack to expose the information needed to get at the assertion. In this form, it likely disappears because it governed the creation of special headers for figuring out how to access assertions and that mechanism won’t be retained in that form. |
exportStdVars | boolean | This was intended to eventually default on and suppress the “standard” variables the SP originally used for a bunch of things. This will become a hub consideration and can be removed. |
exportCookie | boolean | Exposes the cookie name in a standard way to allow manipulation. Was never a fan of this but will have to think on it, and whether this really needs to be content-specific vs. application layer. |
exportDuplicateValues | boolean | Only exists because the current design requires a fair amount of per-request work to do. If we can redesign this to function more sanely up front once, won’t need it, since there’s no value to dups. |
redirectToSSL | unsignedInt | Hacky trick for IIS to support http to https redirects to a specific port. I’d like to hope IIS 7 handles this by now? If not, jeesh. |
entityID | URI | This is a discovery hook, it specifies the IdP to use based on content. Hesitation is that it’s somewhat SAML-specific, at least the name is, but can rename and deprecate. |
entityIDSelf | URI | Similarly, this is the big “avoid overrides for vhosting” feature that overrides the SP name, and should be moved to the hub as an option for computation of the issuer value. |
discoveryURL | URI | Another discovery hook, overrides DS location by content rule. |
discoveryPolicy | string | Likely unused but is a thing the SAML DS spec allows for setting. |
isPassive | boolean | These are all SAML (2) specific settings that override what were originally SessionInitiator options, and came along with the move away from multiple SessionInitiators and the requireSessionWith concept. The question is really whether to go back to that model once the old “chains” of SessionInitiators really just become profile configurations but it’s not entirely clear whether that old model was ever workable. Not all settings are really specific to the IdP you choose, which is where profile configuration becomes workable. If this sticks, clearly these kinds of options have to end up being less tightly controlled and more or less used as an arbitrary set of input options fed into the code for a given protocol that decides how to issue its requests, which is what the model really is now in the SP. |
forceAuthn | boolean | |
authnContextClassRef | list of URIs | |
authnContextComparison | SAML enum | |
NameIDFormat | URI | |
SPNameQualifier | string | |
attributeIndex | string | |
returnOnError | boolean | This is not documented well, I think it was a way to tell a SessionInitiator to silently return in the event of an error, and is implicitly used when isPassive is. Probably needed I guess. |
redirectErrors | URI | Bypasses SP error machinery but works pretty poorly in terms of communicating adequate error specifics. It’s possible if not likely this would just become a default way of handling errors if detailed information needs to be known. |
sessionError | URI | These override the SP error template used for various cases. Error handling like is going to change a fair amount, so this is probably not surviving in this form, but OTOH…dunno. We don’t want error pages to have to be centrally controlled but I don’t know how safe it would be to feed in a Velocity template to the hub either…. |
metadataError | URI | |
accessError | URI | |
sslError | URI | |
target | URI | Very odd use case I never grasped, but basically overrides the RelayState-derived location to send the browser to |
acsIndex | unsignedShort | This isn’t even documented anymore I suspect, and it’s going to go. Just a ridiculous idea, unworkable. |
REMOTE_ADDR | string | This probably shouldn’t be a content setting but it ended up here due to being used during request processing. Again, a hack to compensate for IIS that I have to think would be unneeded by now? I hope? We just should not be in this business. |
encoding | string | Allowed URL encoding of the variables to address Unicode problems, likely still needed but perhaps not at the content level |
attributeValueDelimiter | string | Changes the multi-value delimiter, still needed but perhaps not at the content level |
unset | list of strings | This was added to allow settings to be “cleared” lower in the tree, and Apache itself doesn’t really handle that well, so likely needed. |
Application and Asserting (Relying) Party Settings
These overlap because the way the SP works now is that there are a package of settings you can override via RelyingParty elements (which should have been called AssertingParty) that apply when the IdP involved falls into a particular case by name or metadata tag/group. A few settings are (dubiously I guess) only settable at the Application level but most just get overridden at the RP level.
...