SAML Gap Analysis #4
Comments
|
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. |
|
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. |
|
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
|
|
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. |
|
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: ***@***.***>
|
|
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. |
|
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. |
|
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. |
|
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. |
|
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. |
|
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 :) |
|
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. |
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. |
|
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). 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: |
|
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.
|
As John mentions, I would take a look at SAML2int. There are also a plethora of REFEDS profiles that have been developed in the R&E space in the last decade. Many of these are specific to R&E, but some equivalent profiles to them is something to think about in IPSIE for SAML IMO. For example: The REFEDS assurance framework. RAF Listing of their specifications: https://refeds.org/specifications
Is your reading of 800-63 that to achieve FAL2, that the backchannel is required? That was not my interpretation, only that encryption of the assertion is required and it could be presented via the front channel. I could be wrong though. In any case, back-channel is still supported in federations like InCommon/EduGAIN but has long since fallen out of favor along with things like ECP. |
|
@sbroddy For OAuth 2.0 and OpenID Connect, there's been extensive security tailoring in FAPI, iGov, and MITRE Enterprise Mission-tailored profiles, and those facilitate additional tailoring within downstream profiles. There's no greenfield required for enterprise tailoring of OAuth and OIDC for IPSIE. As you've indicated, there is an enormous install base of SAML, including (government) enterprises. If SAML profiles are used in government to deploy SAML services, or are supported by enterprise vendor products, identifying a short list would seem to be very helpful context, independent of the WG's determination about SAML 2.0 as a part of a profile bundle, "Injection protection" is required for FAL2 in Rev4 (DRAFT), which most readily maps to backchannel. There may be other methods in SAML 2.0 to achieve Injection Protection. I didn't know about SAML2int and I wouldn't be surprised if there is an active "SAML 2.0 Best Common Practice" effort, as well... |
Encryption of the assertion prevents injection, which can be done through the front-channel. The RP has to support encrypted assertions, which is hit and miss. Pretty much all of the open source SAML implementations support it though. And reading that table, it seems they're more worried about SP initiated SAML than anything. But I'd have to re-read it to be sure. Edit: upon a re-read, encrypted assertions don't even seem to be required. It's mainly about RP/SP initiated and the nonce. Both of which my existing deployed IdP and at least some of my RPs already meet.
The nonce, generated by the RP, and then returned within the "InResponseTo" is included within the signed XML generated by the IdP. In that particular case, the RP also accepts encrypted assertions, and my IdP also encrypts, though that isn't explicitly required for FAL2.
Have a look at InCommon's Baseline Expectations also. It's also federation specific, but there are a few useful items there. Everyone in InCommon agrees to meet a minimum operational/security baseline. See also things like the AARC Blueprint, Cappucino/Esspresso assurance levels out of Geant, etc. |
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.
The text was updated successfully, but these errors were encountered: