Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

SAML: A Technical Primer

ssoready.com

Post reply on HN
Print view View original

81–90 of 100 posts

Re: SAML: A Technical Primer

#81

Post by nmadden »

xenophonf wrote: post #59
tptacek wrote: post #23

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…

This cuts both ways. The last major revision of SAML predates the iPhone by several years. Things like PKCE, which are essential for security on mobile devices and in other cases don’t exist at all in SAML, yet the same attack vectors apply (plus a boatload more).

Re: SAML: A Technical Primer

#82

Post by ratiolat »

I really wish that OIDC / Oauth(orization) would be less confusing from user experience and security perspective.

What I have in mind - I'd say only very small population understand that OIDC / Oauth(orization) is about granting access to a service to access your data. Meaning once you have approved service (lets say Dropbox), now Dropbox can access your data on your google account (this of course depends what exactly dropbox asked and if you clicked on "approve", but most people do click as they want to login to Dropbox via their Google account).

SAML is better, as it can be defined at Google side what data is being sent to DropBox when Single Sign On happens and DropBox cannot access your google data as it sees fit.

SAML ain't perfect either because there's no practical way to "sign me out everywhere"

Re: SAML: A Technical Primer

#83

Post by samllmas »

marvel_boy wrote: post #18
eqvinox wrote: post #17

> You care about supporting SAML because your customer wants your product to support SAML. This is sound reasoning on your part. Is it just me or is anybody else going 'the fuck did I just read?' here? It's... incredibly condescending?

It is not you. Also SAML is just a nigthmire.

Mire:

N. a complicated or unpleasant situation from which it is difficult to extricate oneself.

Indeed.

Re: SAML: A Technical Primer

#84

Post by solatic »

No reference to SCIM?

OIDC is far preferable to SAML, but the last time I touched this, half the reason why customers preferred SAML was because their IdP supported SCIM but only for SAML applications.

Re: SAML: A Technical Primer

#85

Post by baq »

eqvinox wrote: post #17

> You care about supporting SAML because your customer wants your product to support SAML. This is sound reasoning on your part. Is it just me or is anybody else going 'the fuck did I just read?' here? It's... incredibly condescending?

It’s a statement of fact…?

Re: SAML: A Technical Primer

#86

Post by terom »

emj wrote: post #27
thrwaway1985882 wrote: post #5

Earlier quoted context omitted.

> 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…

Do you renew the certificates used to distribute the public keys in SAML metadata, and if so why do you do it? I have had a hard time convincing people it is useless to renew those certs and have yet to find an implementation that care about those certificates.

Renewing the certificates seems technically pointless, but some organizations/federations require it.

Rotating the keys would make some sense, but just swapping the cert for a new one issued against the same keys doesn't. It's the easiest way to fulfill those requirements, because you don't need to synchronize the metadata updates, the signatures are always valid with both the old and new cert.

Re: SAML: A Technical Primer

#88

Post by sharat87 »

1270018080 wrote: post #10

Since we're here, I hope someone creates another all encompassing SP/IDP emulator like samltest.id used to until the owner stopped paying. That made my life so much easier as a developer when SAML stuff came up. No one else has come close.

Very beta and work-in-progress, https://littletools.app/saml-provider.

I intend to work on it further once my kid is… well, a little less of a toddler. :)

Re: SAML: A Technical Primer

#89

Post by paulddraper »

unscaled wrote: post #72
paulddraper wrote: post #46

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…

> 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

Huh?

> 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.

You are correct that is the hardest part of SAML, but to be clear, there's a SignatureValue element that is separate from SignedInfo.

And you can use a library to sign. I don't see many implementing their own JWT signatures either.

Re: SAML: A Technical Primer

#90

Post by ucarion »

solatic wrote: post #84

No reference to SCIM? OIDC is far preferable to SAML, but the last time I touched this, half the reason why customers preferred SAML was because their IdP supported SCIM but only for SAML applications.

That's a very fair point! I'm going to add mention of SCIM / directory sync. I feel like it's easiest to stick that into the CISO section, since a big part of SCIM is just the deprovisioning aspect?

And yeah, you're right -- Okta, for example, doesn't let you add SCIM to an OIDC application. It's unfortunate -- there's no deep technical reason you can't mix OIDC and SCIM -- but it is the world we live in.

Post reply on HN