SAML Gap Analysis

[timcappalli]

Based on the discussion on yesterday's call, let's use this issue to start tracking down some technical reasons why SAML may be preferred over OIDC in some deployments.

[aaronpk]

IdP-initiated login

The biggest feature of SAML I hear as an argument for it over OIDC is IdP-initiated login. While it works in OIDC a technically different way than SAML, it is a feature described in OIDC here.

[aaronpk]

To reiterate what I said in the call: while there are certainly some ways to use OIDC in a way that is less secure than SAML, I want to identify all those gaps, and write language into the IPSIE profile of OIDC that makes it so only the secure ways of doing OIDC are allowed in IPSIE.

[sakimura]

Hi. Since I was not in the call, I am lacking the context so might be completely off but OIDC's choice is not LESS secure, but is MORE secure. The SAML way of doing IdP Initiated login is prone to XSRF and is FAL1 in SP800-63-4 2pd.

…

On Thu, Nov 21, 2024 at 1:20 AM Aaron Parecki ***@***.***> wrote: To reiterate what I said in the call: while there are certainly some ways to use OIDC in a way that is less secure than SAML, I want to identify all those gaps, and write language into the IPSIE profile of OIDC that makes it so *only* the secure ways of doing OIDC are allowed in IPSIE. — Reply to this email directly, view it on GitHub <#4 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AABFENYA3YI5OIED6EKMBH32BSZDTAVCNFSM6AAAAABSEVGVEWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDIOBZGAZDCOBXGU> . You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

-- Nat Sakimura (=nat) Chairman, OpenID Foundation http://nat.sakimura.org/ @_nat_en

[aaronpk]

Sorry for the confusion Nat, my two comments here are unrelated. I agree that OIDC's IdP-initiated login is more secure than SAML's. However it was brought up on the call that there are some other ways in which SAML is more secure than some configurations of OIDC, so I want to identify that list so we can make sure to exclude the less-secure options from the OIDC profile.

[sakimura]

Having concore example woulld be very good we dould probably reire the feature.

…

On Nov 21, 2024 at 03:10 +0900, Aaron Parecki ***@***.***>, wrote: Sorry for the confusion Nat, my two comments here are unrelated. I agree that OIDC's IdP-initiated login is more secure than SAML's. However it was brought up on the call that there are some other ways in which SAML is more secure than some configurations of OIDC, so I want to identify that list so we can make sure to exclude the less-secure options from the OIDC profile. — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you commented.Message ID: ***@***.***>

[sbroddy]

IdP initiated login to SAML resources has long been frowned on, despite various vendors' encouragement of the practice. Just one of a multitude of references: link

In my ecosystem, it is rarely used, but on occasion there are RPs that for whatever reason cannot support SP initiated. One particular time reporting system comes to mind, though this has been resolved in later versions of their application.

In my biased opinion, we should not be encouraging IdP initiated SAML today if there is any concern over security.

Back to the original start of this issue, I operate in a SAML federation with >1,000 enterprises, ~700 IdPs, and >6,000 RPs/SPs. And that's before I include my international SAML federation (order of 6,000 IdPs and ~80 interfederated federations). Expecting this number of enterprises and resources to pivot in any near term timeframe is not really reasonable. A pivot of this sort would be akin to IPv4 to IPv6 migrations.

[aaronpk]

I appreciate the migration challenge issue, but setting that aside, I was hoping to learn more about the technical features of SAML that lead it to be preferred over OIDC.

[sbroddy]

I don't know enough about OIDC to effectively weigh in here, but I'm sure there are significant gaps between the two as SAML is used in my ecosystem, and at the scale at which we use it. I'm starting some of these gap conversations amongst colleagues and may have more to weigh in here in the future.

[dickhardt]

Q: is IPSIE guidance for new deployments, or is guidance for how existing deployments can become more secure?

If for new deployments, I believe we want the simplest implementation that provides the desired security. That favors OIDC.

For the latter, one must take into account what is deployed, which favors SAML.

Allowing one of the other requires an IdP to support both, which increases the complexity and attack surface.

Perhaps there should be two different IPSIE specs. One that is SAML based and one that is OIDC based?

The big IdPs deployments will likely support both.

If we take that approach, a SAML task force and a OIDC task force may be the way to divide and conquer the work.

[someknowledge]

Should we provide requirements first and based on those requirements we can choose to keep SAML or not. While there is a security concern about IdP initiated calls, we should not ignore the use case since such use case utilized by many sites.

[dickhardt]

If a goal is for existing SAML deployments to upgrade to a more secure and best practice, not allowing SAML would likely be a non-starter for existing deployments.

Perhaps call it IPSIE for Legacy Deployments :)

[someknowledge]

Is IPSIE backbone OIDC as protocol? If yes, than we should have it in the charter. Otherwise, why are we trying to address multiple security requirements with existing protocol, unless we want to extend the protocol, which will require input from existing body.

[timcappalli]

is IPSIE guidance for new deployments, or is guidance for how existing deployments can become more secure?

For version 1, I'd like to see us focus on new deployments. I'd like us to be able to answer the question of: "I'm building a B2B SaaS app. Which protocols do I need to implement and what are the best practices for integrating with an enterprise identity provider?"

Working to answer this question provides a very clear, focused scope that will allow us to move quickly on a first version.

[Tom-MITRE]

Would it be helpful to collect relevant Enterprise SAML profiles in use, now, as a baseline?

The DRAFT of NIST SP 800-63C-4 introduces comparison across implementations of federation that employ OpenID Connect and SAML (see table).
The table is very high level but identifies the Artifact Binding specification of SAML allows for a back-channel presentation of assertions consistent with that FAL2 requirement: https://docs.oasis-open.org/security/saml/v2.0/saml-bindings-2.0-os.pdf
ACRMinProfile highlights a critical need for OIDC-SAML parity and interoperability.

IPSIE may benefit from a comparison of security features and limitations of OpenID and SAML. Is there an updated SAML 2.0 profile with "2024 security tailoring" applied that we could use as a baseline? Is there a SAML BCP?

The FICAM SAML 2.0 WebSSO Profile is only available from archives at the moment:
https://info.idmanagement.us/2012/10/what-are-ficam-technical-profiles-and.html
https://web.archive.org/web/20130214055629/https://www.idmanagement.gov/documents/SAML20_Web_SSO_Profile.pdf
The FICAM profile cites the Liberty Alliance eGov profile:
https://web.archive.org/web/20220121012046/https://www.projectliberty.org/liberty/content/download/4711/32210/file/Liberty_Alliance_eGov_Profile_1.5_Final.pdf

[ve7jtb]

The most recent SAML 2 profile was one we worked on at Katara https://kantarainitiative.github.io/SAMLprofiles/saml2int.html Thanks I was looking for a copy of the ICAM profiles for historical reasons a couple of weeks ago. SAML artifact binding was a debate at the time but I lost the argument to include it. It was not popular with agencies due to the requirement to open firewall holes mostly. The OpenID Connect code flow works a similar way but is easier to deploy because the server doesn’t need to make a call to the SP. John B.