4 ms·

> Let’s get rid of SAML. Good luck, it's prolific throughout so many enterprises and academic institutions. We might see some support start to materialise for

by lol768 5y ago

> Let’s get rid of SAML. Good luck, it's prolific throughout so many enterprises and academic institutions. We might see some support start to materialise for OIDC as larger enterprises start to make use of e.g. AzureAD properly, but you're still going to see tons of universities especially running their own Shib instance. And larger enterprises are going to be difficult to shift off of SAML when they've had X years of experience with it and their supplier on-boarding processes are built around it. The entire Jisc UK Access Management Federation is based on top of SAML, so that'll power the vast majority of academic resource authentication flows. You can argue that security is less of an issue for this use-case (particularly when e.g. Sci-Hub exists) but I think it's likely that once you have the infrastructure set-up for this it gets used for more and more services.

mordae 5y ago
cough eIDAS cough
- lol768 5y ago
  > eIDAS I'm sure a lot of governments have based regulations and standards on top of SAML... it seems exactly like the sort of thing they'd be drawn to - "mature", more complex than necessary, verbose. Pretty sure Gov.UK Verify is SAML-based, though I get the impression the new single sign-on solution (now entirely in-house with no external IdPs?) will be OIDC based.
avmich 5y ago
> Good luck, it's prolific throughout so many enterprises and academic institutions. Peasy easy. Just start mounting SAML vulnerabilities attacks on all those organizations with friendly suggestions to fix their problems, on top of juicy demonstrations of dangers. After a few will be affected, a trend will appear - in all kinds of media, among other things - that one ought to move from SAML. Of course the teachings should be done remotely, from friendly jurisdictions. /s We have this problem with security for years, not, decades even. Vista (Microsoft OS) was universally hated - <appropriate xkcd picture with blinking Hitler inserted> - as it tried to address gaping holes in XP security; fortunately Win 7 was much more user-friendly, so security still had some wins. But not nearly "ultimate" wins, no.
- tptacek 5y ago
  The problem is that while we're all pretty sure there are more grave SAML vulnerabilities, they're not super easy to find. You can't just read this blog post and then go attack a SAML system; finding SAML bugs is actual research.
  - distortedsignal 5y ago
    Is that... true? I've got a moderate SAML background - written a few SAML services. What sort of attacks (or attack ideas) would you need a research background on in order to judge whether an attack is valid? As an example, one of my projects has pretty good unit/integration test coverage, and the integrations always confirm that the SAML SP will accept/reject valid/invalid assertions. Seems like it would be pretty easy to spin up a REPL and run a bunch of example docs against the service.
    - tptacek 5y ago
      The audience checking authorization vulnerability is a simple example of something that test suites don't tend to cover. Case in point: there's an example of a SAML library on this thread that doesn't even know about audience restrictions.
- tandr 5y ago
  (for a reference to "appropriate xkcd picture with blinking Hitler inserted" - https://xkcd.com/528/ https://xkcd.com/528/ )
user5994461 5y ago
The largest enterprise support OIDC just fine. Active Directory support both SAML and OIDC as of version 2016. Okta and similar support both indifferently. SAML had a head start of a few years but OIDC caught up. It's helping that all social sign-on are exclusively OIDC.
- raziel2p 5y ago
  Anecdotal but many on-premise applications I've worked with recently didn't work with our SSO when I tried using OIDC, but worked fine using SAML. The reasons were various, none were really valid.

by lol768 5y ago

mordae 5y ago

cough eIDAS cough

lol768 5y ago
> eIDAS I'm sure a lot of governments have based regulations and standards on top of SAML... it seems exactly like the sort of thing they'd be drawn to - "mature", more complex than necessary, verbose. Pretty sure Gov.UK Verify is SAML-based, though I get the impression the new single sign-on solution (now entirely in-house with no external IdPs?) will be OIDC based.

avmich 5y ago

> Good luck, it's prolific throughout so many enterprises and academic institutions. Peasy easy. Just start mounting SAML vulnerabilities attacks on all those organizations with friendly suggestions to fix their problems, on top of juicy demonstrations of dangers. After a few will be affected, a trend will appear - in all kinds of media, among other things - that one ought to move from SAML. Of course the teachings should be done remotely, from friendly jurisdictions. /s We have this problem with security for years, not, decades even. Vista (Microsoft OS) was universally hated - <appropriate xkcd picture with blinking Hitler inserted> - as it tried to address gaping holes in XP security; fortunately Win 7 was much more user-friendly, so security still had some wins. But not nearly "ultimate" wins, no.

tptacek 5y ago
The problem is that while we're all pretty sure there are more grave SAML vulnerabilities, they're not super easy to find. You can't just read this blog post and then go attack a SAML system; finding SAML bugs is actual research.
- distortedsignal 5y ago
  Is that... true? I've got a moderate SAML background - written a few SAML services. What sort of attacks (or attack ideas) would you need a research background on in order to judge whether an attack is valid? As an example, one of my projects has pretty good unit/integration test coverage, and the integrations always confirm that the SAML SP will accept/reject valid/invalid assertions. Seems like it would be pretty easy to spin up a REPL and run a bunch of example docs against the service.
  - tptacek 5y ago
    The audience checking authorization vulnerability is a simple example of something that test suites don't tend to cover. Case in point: there's an example of a SAML library on this thread that doesn't even know about audience restrictions.
tandr 5y ago
(for a reference to "appropriate xkcd picture with blinking Hitler inserted" - https://xkcd.com/528/ https://xkcd.com/528/ )

user5994461 5y ago

The largest enterprise support OIDC just fine. Active Directory support both SAML and OIDC as of version 2016. Okta and similar support both indifferently. SAML had a head start of a few years but OIDC caught up. It's helping that all social sign-on are exclusively OIDC.

raziel2p 5y ago
Anecdotal but many on-premise applications I've worked with recently didn't work with our SSO when I tried using OIDC, but worked fine using SAML. The reasons were various, none were really valid.