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

91–100 of 100 posts

Re: SAML: A Technical Primer

#91

Post by bitexploder »

Jerrrrrrry wrote: post #51
poincaredisk wrote: post #33

Earlier quoted context omitted.

Is it that different from parsing JSON? A honest question, what's the difference? Billion laughs attacks and similar?

A computer scientist would say they have identical parsing complexity, so not much. A computer programmer wouldn't even know where to begin, as the chesterton's fence had long been rejustified

But it’s not true in practice. Pure simple XML vs JSON sure. XML you deal with in SAML has tons of extra things like namespaces, canonicalization issues, etc. it is way more complex and has led to many security issues over the years.

Re: SAML: A Technical Primer

#92

Post by mooreds »

ucarion wrote: post #74
mooreds wrote: post #56

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…

Yeah, I didn't even mention the other bindings (HTTP-Redirect, Artifact, etc.) because they're not widely supported. Only SAML's HTTP-POST binding enjoys "every IDP supports this exact protocol" status. 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, a…

We've found some usage of http-redirect and support it. But we've gotten requests for Artifact and other more esoteric features (encrypted assertions). It's definitely an example of the 80/20 rule.

> We just implement SAML RelayState / OAuth `state` via good old database persistence.

I'm not sure I understand how this helps. You still need to support the parameter so that folks can pass information through the login state (for deeplinking, among other use cases). Which means you still need to process it and therefore are committed to either being noncompliant with the spec or providing functionality that is limited to 2005 sensibilities.

What am I missing?

Re: SAML: A Technical Primer

#93

Post by Terretta »

davewritescode wrote: post #35
Terretta wrote: post #6

Earlier quoted context omitted.

(S)uggest (A)lternative (M)odern (L)ogin: OIDC/Oauth2 ? The "Continue with" buttons that include Microsoft, Google, and Apple, tend to pick up most SMBs without SAML SSO headaches on either side. Like so: https://www.xsplit.com/user/auth https://id.atlassian.com/login Use an email domain restriction, and you have by and large SSO; the user can only log into your SaaS if the user is an active account at that company.…

As someone who worked at a very large SaaS company this is a good recommendation if the vast majority of your customers come from large enterprises with competent IT departments. The problem is when you work with smaller shops that don’t have IT departments or worse bad IT departments you’re going to pay a fortune in support costs. Use an open source identity provider or pay someone to do it for you.

I'd argue you're half right.

Yes, it is a good recommendation if the customers have an IT Department.

But I'd argue you're missing the other half.

It's an even better recommendation if the customer is using M365, Google Workspaces, or Apple Business Manager, without an IT Department, since they don't need an IT Department at all to get effectively the same benefit as SSO.

After your initial setup to accept OIDC as the SaaS or PaaS, neither you nor the customer have to do an "integration" to support additional customers of Microsoft, Google, or any other OIDC provider you add. You could let your customer validate an email domain to ensure their sign-ins are theirs, but other than that, once you support OIDC with their provider, nobody has to do anything.

Something on the order of 80% of SMB in the U.S. are on O365/M365 by some measures, and judging from startups here, every tech startup thinks everyone's on Google Workspaces like they are, so that's the other 80%. :-) Toss in socials if you are B2C instead of B2B, and of course Apple IDs if you are targeting users by "wallet share".

You get the key benefit of SSO while your clients do not need to integrate one by one. And...

> Use an open source identity provider or pay someone to do it for you.

Or, don't do that effort at all, use what's baked in and just take the win.

Re: SAML: A Technical Primer

#94

Post by solatic »

ucarion wrote: post #90
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.

> a big part of SCIM is just the deprovisioning aspect?

The "just" makes it sound like this is a minor point. This is a huge point. Enterprises are forced by their customers and regulators to show that terminated employees lose access immediately. There are two ways to make that happen: force everything to flow through a VPN, and SCIM. Most SaaS providers do not support IP allowlisting needed to enforce that all traffic flows through the VPN, and the only alternative to enforce that user sessions are terminated immediately is if the SaaS keeps sessions in a database and those sessions are revoked as part of SCIM. Otherwise the sessions could continue to be valid for days or even longer, presenting a risk of allowing terminated employees to wreck untold havok.

Re: SAML: A Technical Primer

#95

Post by ucarion »

mooreds wrote: post #92
ucarion wrote: post #74

Earlier quoted context omitted.

Yeah, I didn't even mention the other bindings (HTTP-Redirect, Artifact, etc.) because they're not widely supported. Only SAML's HTTP-POST binding enjoys "every IDP supports this exact protocol" status. 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, a…

We've found some usage of http-redirect and support it. But we've gotten requests for Artifact and other more esoteric features (encrypted assertions). It's definitely an example of the 80/20 rule. > We just implement SAML RelayState / OAuth `state` via good old database persistence. I'm not sure I understand how this helps. You still need to support the parameter so that folks can pass information through the login…

What I'm saying is you can implement the functionality of the parameter -- i.e., arbitrary data that survives a round-trip through a SAML login -- without literally using RelayState.

For example, the ID of a SAML `AuthnRequest` always gets echoed back to you in the SAML `Response`. So you can use that as an opaque identifier. You store ID/state pairs in the database when you start SAML logins, and look them back up when the assertion comes back to you. Basically, that's what we do on behalf of our customers.

It's a bit more work for us to implement, but it gives SSOReady customers the "deeplinking" functionality without the weird caveats that RelayState carries.

Re: SAML: A Technical Primer

#96

Post by ucarion »

solatic wrote: post #94
ucarion wrote: post #90

Earlier quoted context omitted.

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.

> a big part of SCIM is just the deprovisioning aspect? The "just" makes it sound like this is a minor point. This is a huge point. Enterprises are forced by their customers and regulators to show that terminated employees lose access immediately. There are two ways to make that happen: force everything to flow through a VPN, and SCIM. Most SaaS providers do not support IP allowlisting needed to enforce that all traf…

Oh don't get me wrong at all -- deprovisioning is huge indeed!

I'm not going to misleadingly edit my initial comment, and your comment is fair. I said "just" when I should have said "precisely". As in, I was already talking about how SAML interacts with "Bob from Sales got fired, probably should kick him out of the CRM". SAML gives you "Bob can't log into the CRM ever again", SCIM gives you "... and his CRM user and sessions are immediately revoked".

To be clear, SSOReady also has a "SCIM made easy" API, we definitely know about and care about helping people implement SCIM: https://ssoready.com/docs/scim/scim-quickstart

Re: SAML: A Technical Primer

#97

Post by Jerrrrrrry »

bitexploder wrote: post #91
Jerrrrrrry wrote: post #51

Earlier quoted context omitted.

A computer scientist would say they have identical parsing complexity, so not much. A computer programmer wouldn't even know where to begin, as the chesterton's fence had long been rejustified

But it’s not true in practice. Pure simple XML vs JSON sure. XML you deal with in SAML has tons of extra things like namespaces, canonicalization issues, etc. it is way more complex and has led to many security issues over the years.

I had originally quoted

  "in theory, it's easy in practice. in practice, its easy in theory"
But I thought scientist vs. programmer would be literally analogous and rivet more finches.

Re: SAML: A Technical Primer

#99

Post by emj »

terom wrote: post #86
emj wrote: post #27

Earlier quoted context omitted.

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.

Make senses, most bigger federations do not bother with this luckily for us it is just specific idps.

> synchronize the metadata updates

Sadly I know many implementations that do not handle key changes in the metadata in a smooth way. The two SPs I have from Adobe both require manual updating of one key per idp, making a switch pain to synchronize.

Re: SAML: A Technical Primer

#100

Post by thrwaway1985882 »

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.

All my x509s for SAML signing are self-signed, and all my self-signed certs live for 9999 days and I plan to let someone else figure out the fallout from that as I'm going to be /retired/. No one has ever really complained. Some IdPs I've integrated with use certificates that are signed by public CAs and it's always a hassle because the ergonomics around it are terrible.

IMO, I think rotation is wildly useless too. It might make sense in a world where my signing certificate was decoupled from the metadata someone else has to very likely load by hand.

Post reply on HN