...
Name | Type | Location | Notes |
|---|---|---|---|
id | string | Application | Keys the override mechanism, hacky trick used currently that locks the root element to an id of “default”, clearly will need to change. |
entityID | URI | Application, RelyingParty, Content | This was the original way to specify the SP name, but it feels a lot like the original IdP mistake to put it as a RelyingParty setting and not a ProfileConfiguration item. My sense is we end up leveraging this for compatibility but newer configs would delegate the entityID to the hub. |
homeURL | URI | Application | This is a default “if no RelayState” pointer to where to go and almost always just the root of the site but I’m sure people have used it. Definitely contaminates this area of the system with “content” awareness in some sense, creating a challenge to decouple things. |
policyId | string | Application | Definitely dead since it ties into security processing, but the interesting note is that it never got included as an RP setting, possibly due to order of processing concerns knowing who the IdP is early enough. It does show up down at the individual protocol handler shortcut level. Either way, dead. |
REMOTE_USER | list of strings | Application | Very odd that this shows up here, nowhere else, and REMOTE_ADDR was only a content setting. That’s due to the latter coming much later. Seems clear we would NOT have defined REMOTE_USER here originally and it likely needs to migrate out to a Content setting. Making it IdP-specific is an interesting idea but may be difficult to pull off. |
unsetHeaders | list of strings | Application | Not used really at all, allows the set of headers to clear to be custom. The whole area is a problem of course since it was very hard to make headers even close to safe and it ended up tied very closely into the attribute processing layer, which will be…very hard to translate clearly, but we have to somehow. |
attributePrefix | string | Application | These allow the variable names to be adjusted on the fly. The basic one is pretty simple and helps out with things like AJP proxying, and is likely needed somewhere. The metadata one is just…odd, and had to do with the original support for sucking tags out of metadata and stuffing them into attributes. I don’t know if we can just drop it, I should have added a deprecation warning I suspect. If we need it, we need it, the idea was just that a particular SAML Attribute might be about the IdP and not the subject. |
metadataAttributePrefix | string | Application | |
requireAuthenticatedEncryption | boolean | Application | This is just odd, I don’t know why this ended up here. Clearly should have been a policy layer concept or handled in some better way, but we’ll definitely support it, just not like thisI’m not sure it makes much sense really. Must have been some attempt to incentivize GCM support but no SP is going to care, it’s not their data. |
handlerURL | URI | Application | This is certainly content-related, but it’s also tied pretty tightly up with the metadata needed to make things work if it’s actually changed, so might be better to divorce it from the agent and have it managed more as an IT “task” if it really has to be different (the agent would need to know it, but may not need to be able to change it on that end). |
handlerSSL | boolean | Application | Probably more an agent consideration I suppose but then runs into security policy I guess. |
exportLocation | URI | Application | Should both go away if we can shift to a different model for assertion access, which I hope we can do. |
exportACL | list of IPs | Application | |
cookieName | string | Application | All sort of connected mostly to session cache handling, though the props apply to other cookies also. Will depend on session design I think. Lifetime is used to push cookies out across restarts. |
cookieProps | string | Application | |
cookieLifetime | seconds | Application | |
sameSiteSession | Enum | Application | Another cookie property that more or less applies to all the cookies used. |
sameSiteFallback | boolean | Application | The hack for old Mac and Android support. Might be a good chance to just drop that. |
idpHistory | boolean | Application | Dropping for sure |
idpHistoryDays | days | Application | |
idpHistoryProps | string | Application | |
lifetime | seconds | Application | Session cache policy for the application, obviously needed but will depend on design there. Another of those “probably something the agent should be able to influence” things. |
timeout | seconds | Application | |
maxTimeSinceAuthn | seconds | Application | This is only enforced at acceptance time, so this is really a security policy setting, but it may need to be agent-driven because it’s the only practical way to make ForceAuthn useful. |
checkAddress | boolean | Application | This is the cross check with the assertion, so I suspect it will be sufficient to manage this at the hub. Kind of simplifies the problem really. |
consistentAddress | boolean | Application | This is session cache policy so likely will be agent-driven in part |
postData | string | Application | The POST data preservation support, this only applies to the SSO boundary right now. Definitely more of a hub consideration I suspect and may have to be turned into something more general perhaps. |
postLimit | bytes | Application | |
postTemplate | string | Application | |
postExpire | seconds | Application | |
relayState | string | Application | This will be a hub issue |
redirectLimit | enum | Application | Probably needs agent control but could be debated |
redirectAllow | list of URIs | Application | |
authType | enum | Application, RelyingParty | Not the same as the content setting, this was for SOAP communication, definitely gone (in this form) |
authUsername | string | Application, RelyingParty | Used for some of the SOAP authType values, gone |
authPassword | string | ||
signing | enum | Application, RelyingParty | Controls signing and encryption, definitely moving to hub and to a form consistent with IdP. I think most of the behavior was already modeled by the IdP when it comes to “conditional” signing or encryption but will need review |
signingAlg | URI | ||
digestAlg | URI | ||
encryption | enum | ||
encryptionAlg | URI | ||
keyName | URI | ||
artifactEndpointIndex | string | Application, RelyingParty | Seriously doubt we will bother supporting outbound artifact binding. |
chunkedEncoding | boolean | Application, RelyingParty | SOAP related, definitely gone |
connectTimeout | seconds | Application, RelyingParty | SOAP related, definitely gone |
timeout | seconds | ||
cipherSuites | string | SOAP related, definitely gone | |
requireConfidentiality | boolean | Application, RelyingParty | SOAP related, but will have to review if this is addressed. The IdP doesn’t generally support outbound SOAP with protocols that receive data, so it’s less prone to the problem of using http but getting an unencrypted response. Of course, http isn’t too common anymore either. |
requireTransportAuth | boolean | Application, RelyingParty | SOAP related, will need review to ensure semantics are handled. |
requireSignedAssertions | boolean | Application, RelyingParty | Profile config option I imagine |
sessionHook | URI | Application, RelyingParty | Definitely needed and probably has to be agent driven |
artifactByFilesystem | boolean | Application, RelyingParty | Dead, part of old hacky trick in the SP for pluggable authn |
requestDelegation | boolean | Application, RelyingParty | Already undocumented, part of the deprecated delegation work that’s pulled from V5 |
authnContextClassRef | URI | Application, RelyingParty | In this context they’re like profile config options, but they’re also content settings. Arguably the content setting part is how the agents override profile options set on the hub, but TBD. |
authnContextComparison | SAML 2 enum | ||
NameIDFormat | URI | ||
SPNameQualifier | string | ||
attributeIndex | string |