71–80 of 100 posts
The incredible overengineering of the XML signature specification is certainly to blame for this recent SAML verification vulnerability (from the same site): https://news.ycombinator.com/item?id=41586031
Earlier quoted context omitted.
I investigated both and implemented OIDC. It was difficult, but compared to the SAML and XML complexity, I'd say it was much easier.
XML is marginally more complicated than JSON: attributes and namespaces. Apples to apples, is it's not much different. XSD is just as complex as JSONSchema. Verbose? Sure. But people love XML so much, they invented JS-and-XML (JSX). :shrug:
No, the main problem with SAML is that it relies on XML Signatures (XMLDSig). And the main problem with XML Signatures is that the signature needs to be embedded inside the XML it's signing, instead of being attached to it, like every other signature standard on the planet.
[1] The added complexity is not just attributes and namespace, but also entities, DTD and processing instructions. If you want even the most basic type checking, XML schema becomes mandatory. This is important, since JSON doesn't need a schema for handling basic types, and in fact OAuth 2.0 and Open ID Connect do not rely on JSON Schema at all.
[2] See the OWASP cheatsheet for all the ways accepting XML input from the internet can put your application in danger: https://cheatsheetseries.owasp.org/cheatsheets/XML_Security_...
No equivalent document exists for JSON.
Earlier quoted context omitted.
Oh, I thought it stood for: "Suffering A Massive Lot" - jk Let's just say my interaction with managing websites that used SAML was less than pleasant.
> Let's just say my interaction with managing websites that used SAML was less than pleasant. My interactions supporting it as both the identity provider & the service provider have lead to me being the SAML person at work, and I'm now very used to people either laughing at my misfortune or giving me pitiful looks. It combines all the wonderful antipatterns you can name: a protocol where near everything is optional a…
Also worth noting that per the spec, the RelayState can only be 80 bytes. > As well in "HTTP Redirect Binding" or "HTTP POST Binding", The RelayState value MUST NOT exceed 80 bytes From https://docs.oasis-open.org/security/saml/v2.0/saml-bindings... At FusionAuth, we have an open issue for this: https://github.com/FusionAuth/fusionauth-issues/issues/2467 which you can read for more details. SAML is full of these kind…
FWIW, the for library I work on -- github.com/ssoready/ssoready -- we sidestepped this issue by simply not using SAML RelayState at all under the hood. Between the fact that it's vulnerable to attacker manipulation, and the size limits, it's not worth the pain. We just implement SAML RelayState / OAuth `state` via good old database persistence.
Earlier quoted context omitted.
That was my understanding and also my plan, but it does not seem feasible to force this as the vendor of the software. If the customer says they need SAML at some point the business side will require that it is implemented. I do want to try and get as far with only OIDC as possible, but I am a bit worried that some larger customer might just bulldoze through because they only want SAML. Might be much more likely for…
We've managed to hold the line on OIDC so far. So has Tailscale. If Tailscale can hold the line, given who they're selling to, I think most orgs can. Really, try to avoid doing SAML. Remember, as a vendor, you're often competing with companies that don't do real SSO integration at all. At the very least: if I was ever to do SAML, I would rip your face off in the pricing for it.
Earlier quoted context omitted.
XML is marginally more complicated than JSON: attributes and namespaces. Apples to apples, is it's not much different. XSD is just as complex as JSONSchema. Verbose? Sure. But people love XML so much, they invented JS-and-XML (JSX). :shrug:
The problem is not XML by itself. XML adds a considerable amount of complexity to JSON[1] and when writing security-oriented software complexity matters quite a bit[2]. But this is still a level of complexity that can be managed. Most other XML-based protocols aren't as bad as SAML. No, the main problem with SAML is that it relies on XML Signatures (XMLDSig). And the main problem with XML Signatures is that the signa…
Earlier quoted context omitted.
The problem is not XML by itself. XML adds a considerable amount of complexity to JSON[1] and when writing security-oriented software complexity matters quite a bit[2]. But this is still a level of complexity that can be managed. Most other XML-based protocols aren't as bad as SAML. No, the main problem with SAML is that it relies on XML Signatures (XMLDSig). And the main problem with XML Signatures is that the signa…
XML=JSON=YAML=TDL (tree describing language)
Everyone in here is saying SAML is dead and long live OIDC. The company I work for has SAML support, but not OIDC. As far as I understand it, all the customers are asking for SAML. I've never heard a request for SAML. This is in the health care sector.
Earlier quoted context omitted.
The problem is not XML by itself. XML adds a considerable amount of complexity to JSON[1] and when writing security-oriented software complexity matters quite a bit[2]. But this is still a level of complexity that can be managed. Most other XML-based protocols aren't as bad as SAML. No, the main problem with SAML is that it relies on XML Signatures (XMLDSig). And the main problem with XML Signatures is that the signa…
XML=JSON=YAML=TDL (tree describing language)
This is a very weird page, as it seems to suggest that SAML is the only way to do single sign-on integration with IdPs like Okta. But modern systems all do OIDC, which is what you should do. You need a much better reason to support SAML than "the CISO wants it so they can use Okta", because the CISO can (and should) just use OIDC.
> just use OIDC OIDC doesn't scale, and OIDC Federation is still in draft. SAML Federation is mature with wide support and good discovery UX thanks to SeamlessAccess. SAML has a variety of standard attribute bundles, entity categories, frameworks, and profiles covering important integrations, e.g., identity assurance. These are slowly being defined in (or ported to) OIDC. I like OIDC and think highly of the people wo…
The things you just listed sounds like unnecessary complexity that inevitably leads to the “too big standard” problem, where every vendor and id provider has their own half assed, incomplete and incompatible implementation of the standard, or worse - with security bugs. Something quite often seen with SAML.
That’s not to say that oidc or oauth doesn’t have alignment issues. See https://news.ycombinator.com/item?id=35713518 “We implemented OAuth for the 50 most popular APIs. TL;DR: It is still a mess”