SAML and IdP initiated federation flows

[deansaxe]

In #94, the language was changed to require RP initiated federation flows. SAML often uses an IdP initiated federation, e.g. from the Okta dashboard. While this has known security issues (see https://www.identityserver.com/articles/the-dangers-of-saml-idp-initiated-sso), it is also commonly used.

How do we want to handle this moving forward? I see two choices:

1. Move the requirement for RP initiated flows to SL2, allowing them to continue at SL1 for SAML implementations
2. Keep the requirement at SL1 and figure out how to device a mechanism for SAML that works similar to https://openid.net/specs/openid-connect-core-1_0.html#ThirdPartyInitiatedLogin

[mcguinness]

I think we need to to relax SL1 requirements to enable the majority of real-world enterprise deployments live today to be compliant with as minimal changes as necessary. The lack of a interoperable/deployed 3P initiated login mechanism for SAML is significant blocker for SL1 compliance and would mean the majority of deployments today have no path to SL1 conformance without adoption and deployment of a yet to be defined extension to a protocol that has enough evidence that investments in evolving implementations has limited ROI.

As with some other issues we identified, higher SL levels can require IdP-init if necessary as this forces a tradeoff question of whether the path forward is easier resolved by adoption of OIDC or further investments in SAML.

I think we can put a reasonable box around requirements for IdP-init

• Assertions are short-lived, audience constrained, must be 1-time use and RP must prevent replay attacks of same Assertion ID
• SAMLResponse must only be POSTed to a HTTPS URL approved during application on-boarding (e.g. shouldn't be dynamic)
• SAML SP Service Provider endpoints meet all the DNS/TLS requirements we have outlined in common criteria
• User Authentication Intent must be enforce by the IdP via interactive confirmation or similar mechanism (e.g MFA Prompt) to prevent silent authentication to an app

[sbroddy]

IdP initiated login is quite rare in my ecosystem, so I disagree that the majority of deployments today would have no path to SL1. I suppose it depends on how we're defining "the majority".

Option 2 will be problematic for RPs that still do not support RP initiated login. They're extremely rare in my world, but do still exist - and are often the only reason IdP initiated SSO would be considered in my ecosystem.

User Authentication Intent must be enforce by the IdP via interactive confirmation or similar mechanism (e.g MFA Prompt) to prevent silent authentication to an app

In many/some cases, this would require modifications to Identity Providers, so is also problematic.

[mcguinness]

I suppose it depends on how we're defining "the majority".

Fair, this is well defined. I was referencing experience with Okta workforce deployments which according to some analysts has ~33% market share for enterprise SSO and extrapolating for the other 2 leading platforms (Entra and Ping).

In many/some cases, this would require modifications to Identity Providers, so is also problematic.

Many of the widely deployed workforce IdPs can enable MFA challenges using policy controls without changing their SSO implementation to satisfy a minimal "authentication intent" interaction. In general IdPs would need to modify app onboarding flows for IPSIE to auto-configure the right subset of capabilities needed for IPSIE conformance. One design goal IIRC was to reduce changes to SPs in favor of IdPs as their are fewer IdPs as well.

[sbroddy]

~33% market share for enterprise SSO

Keep in mind that those market numbers typically exclude most of the participants in the largest global-scale SAML (inter)federation I am aware of with a globally deployed footprint of >6,000 SAML IdPs and >200M users. That also includes ~1,000 participating US enterprises before even counting international participants.

[alexbchalmers]

There is an Option 3 here, which is keep the requirement at SL1 and not permitting IdP-init for SAML connections under IPSIE. This would be justifiable under the consideration that IPSIE is attempting to limit optionality for secure interop. IdP-init is not a mandatory part of the SAML spec (saml-profiles sec 4.1.5 indicates an IdP MAY provide unsolicited responses and SPs SHOULD be prepared to handle a successful response).

Option 1 is really unappealing. I don't think there are many arguments for IdP-init outside of not wanting to impact existing configurations. Meanwhile, there are multiple arguments against IdP-init.

Unfortunately, Option 2 is not viable given SAML's semantics and the optionality provided in sec4.1.5. That said, there is absolutely a similar mechanism as that used by OpenID Connect provided by at least some SAML IdPs, especially if they provide some sort of application picker interface. In this case, storing a URL provided by the SP that kickstarts an AuthnRequest often with helper parameters to select the appropriate upstream IdP and branding. This is outside the SAML spec but is still supportable. Pairing this with a configuration that blocks IdP-init could be used to provide similar capability without the negative side-effects.

This option would undoubtedly exclude some number of SPs from being IPSIE compliant. I don't think this is necessarily a bad thing, nor an undesirable outcome. We have consistently discussed that nothing that IPSIE does should be taken as blocking functionality within the underlying protocols or systems. This option does nothing to prevent SPs that require IdP-init to be blocked by IdPs. Similarly, we have discussed IPSIE as being a driver for apps and IdPs to implement secure, interoperable options. This option provides the direct path for those impacted SPs should they find IPSIE compliance relevant, namely, implementing or requiring SP-init.

[sbroddy]

That said, there is absolutely a similar mechanism as that used by OpenID Connect provided by at least some SAML IdPs, especially if they provide some sort of application picker interface. In this case, storing a URL provided by the SP that kickstarts an AuthnRequest often with helper parameters to select the appropriate upstream IdP and branding.

Some variation of that is usually my suggestion for when people really want a NASCAR style app portal. Just redirect the user to the SP to kickstart the flow instead of starting the flow at the IdP. Where this fails is SPs that literally can't support SP initiated. The last one of these I ran into was an old, but still supported by the vendor, version of time reporting software that was still in use. This happened about 18 months ago... so they're still around.

IMO, if an IdP supports SP initiated SAML, and uses it for the vast majority of its RPs, I would suggest the case could be made that the IdP is not non-compliant just because it still has a few random RPs that still insist on IdP-initiated, assuming that the support for that is on an per-exception basis. It just means the SP is non-compliant, and the IdP has to accommodate it.

I would, however, strongly discourage wide-scale usage of IdP initiated. But then, it's also largely not a problem in my ecosystem.

[mcguinness]

Just redirect the user to the SP to kickstart the flow instead of starting the flow at the IdP. Where this fails is SPs that literally can't support SP initiated

This the gap that this issue is bringing up, 3P initiated login. You often need a login_hint and sometimes a domain or tenant hint to enable the RP to init login without asking the user for inputs and leaving them stuck on a screen. A simple redirect isn't enough leaving each SP to define custom query params/etc.

This is basically just saying Option 2.

[sbroddy]

This is often solved via discovery services and/or email based discovery as just two other options.

Discovery services are largely frowned upon outside of my sector, though for instance the major journal publishers have adopted it. Email discovery is also bad(tm) for reasons, but that ship has long sailed.

There aren't zero solutions... there are just solutions that don't seem to be favored over IdP initiated, which for obvious reasons is also bad.

[sbroddy]

I've also seen RelayState required by RPs for purposes like this. It seems to be pretty rare among my SPs, but there do seem to be SPs that require it for things like this.

Profiles for the OASIS Security Assertion Markup Language (SAML) V2.0

4.1.5 Unsolicited Responses
... Of special mention is that the identity provider MAY include a binding-specific "RelayState" parameter that
indicates, based on mutual agreement with the service provider, how to handle subsequent interactions
with the user agent. This MAY be the URL of a resource at the service provider. The service provider
SHOULD be prepared to handle unsolicited responses by designating a default location to send the user
agent subsequent to processing a response successfully.

[deansaxe]

Thank you all for the discussion and debate.

In order to move forward, I suggest someone take the pen and suggest language for SL1 (and maybe SL2) in the levels doc, and matching normative language in the common requirements profile. Once we have proposed language we'll be able to work toward consensus on the path forward.