
Why your SaaS application should support SAML - zrail
https://www.petekeen.net/why-your-saas-application-should-support-saml
======
Steeeve
Decoupled authentication from your application should be part of any base
architecture these days.

The article is thin on details, but adding SAML authentication to the mix
shouldn't be terribly difficult if you have somebody on board or bring
somebody in who knows it already.

Learning how to do it without any experience is fraught with problems. The
documentation is hard to absorb with all kinds of abstracted out concepts and
important settings that are easy to overlook (like requiring encrypted
assertions). And really, the more you dig into it the more complex it seems to
be, when on the surface the concept is very simple. Unfortunately, that's one
of the reasons that libraries supporting SAML aren't as widely available as
they should be given it's age.

It's kind of like SOAP. If you know what you're doing and you've done it
before, it's simple. If you're brand new to it, you're left twitching and
angry at the end of a weekend coding session.

Regardless, decouple your authentication mechanisms and be prepared to add
support for a new technology as necessary. Don't just think about end users,
think about automation, how you might support it, and how it behaves
differently.

~~~
newscracker
I wouldn't suggest anyone to develop SAML support on their own unless they
want to sell that as a component or service by itself. Instead, I'd strongly
recommend that they look for libraries that have been around for sometime that
take the grunt work out and provide high level APIs for the application to
invoke. With this approach, supporting SAML becomes a whole lot easier and
quicker to accomplish. One may have to pay real money though, depending on the
platform, framework and language. Free ones in this area, to the extent of my
research, come up short on reliability.

Also, the most common use cases are related to browsers, and don't need the
entire specification of SAML to be implemented, like all the profiles, for
example.

------
Improvotter
I can personally vouch for this imo silly little thing. It once came up in a
meeting to which we said we could implement it immediately. You try explaining
some stuff to totally tech illiterate people that make the business decision
for a government company that needs to publicly do this. It's one big mess,
they have to publish reasons and comparisons between several companies and
they didn't make any sense when you read them because the people writing them
didn't have any any of what they were talking about. You'd often find words
like databases, servers, the cloud, and more words strewn around everywhere
without making even the closest sense as to what they mean.

After that meeting, when someone asked us whether our stuff is in the cloud,
we just said yes.

When they asked us whether we had SAML, we said yes.

When they asked whether we had x, again, we said yes.

It's not possible to explain to these people that you'd like to talk to
developers or at least people who were trained at some point in their life.

~~~
cosmie
As someone who has had to become fluent in Executive, Project Management,
Bureaucratic Procurement, Software Development, and Operations (I consider
each of those completely distinct languages), I can empathize.

The best way I've found to improve on that type of pain is to try to shadow as
many similar interactions as you can, but with people speaking the same
language on both sides of the table, while having a lot of visibility into one
side so you understand how their response differs from what yours would be in
that situation. Unless something is horrifically wrong in a way which has
clear consequences, I generally stay silent and keep my interjections to
myself. And at most follow up after with the person "on my side" to try to
explain to them, and let them decide if it matters enough to bring up. If they
can't see the problem, it's generally useless to bubble it to the other party
who has even less understanding of your position. I've learned a lot that way
about how to appropriately articulate the same situation to each of those
stakeholders.

In your situation, the way I've learned to handle it is always a "Yes, our
system is designed to be able to support that." The buyer side just has a list
of checkboxes that at some point distill down to a bid. They have no idea what
the checkbox means, nor care. But they understand that bids have a lot of
variables. If you as the technical resource know that it's possible to, in
some warped sense, adhere to that definition, then it's a yes. But never a
hard yes - every check box on their end is a potential to pull out a cost. If
you have to develop SAML support, but know that it's a net new feature that'll
need integrated into your auth system, then it's a "Yes, we're capable of
supporting that." followed by an explicitly called out segment of your bid
that pushes the anticipated development cost onto them as a line item denoting
the cost for that feature's support and it becomes another negotiation point.
Maybe they don't need that checkbox, if the cost is too high. Or maybe you can
frontload the entire development cost of that feature onto that one customer,
and it's an inconsequential expense for them. Or maybe they need it, but
aren't willing ot fully absorb that development cost and push back. You don't
know, and they don't either if you just say yes and try to work out the math
on your side to make it work.

------
isaack
For people on the "hipster" train of SPA/JWT etc, I found OpenID Connect (not
the original OpenID) incredibly useful. With a simple JS library [1] you can
ask your users to log in with Google, Microsoft, etc, and you can then
validate the JWT tokens issued on the server-side.

[1]: [https://adodson.com/hello.js/](https://adodson.com/hello.js/)

~~~
tonyarkles
OIDC is definitely my preferred approach, but that's kind of the point of the
article. Big orgs & governments, today, are generally going to be using SAML,
if you're lucky (other times they're going to ask you to integrate directly
with their 2-decade-old Active Directory).

SAML's kind of quirky, but the handful of integrations I've done so far
haven't been _that bad_. Most of the pain comes from all of the half-baked
implementations. I used to get riled up when a customer would ask "can you
please not use signed or encrypted assertions? Our side doesn't support
that"... now I just mostly shrug, make sure we're doing it over HTTPS, and...
meh.

~~~
zwily
A not-encrypted assertion over https makes sense, but not signed?!?!?

~~~
tonyarkles
> but not signed

That's right... Key management is hard lets go ride bikes.

------
haser_au
SAML SaaS providers are increasingly used over internally hosted SAML servers
like Microsoft ADFS. Okta and Ping, to name a few, make things extremely easy
for internal security teams, and likewise for SaaS providers.

I have been on the implementation team inside a large enterprise for Okta and
MS ADFS. It was far easier for me to say to SaaS providers "make sure you
integrate with Okta" vs having a series of technical meetings to implement a
specific configuration for ADFS. It outsources risk, and means SaaS providers
only have to manage the integration with one provider for a potentially large
customer base.

~~~
nl
Yes. Basically there are two ways to do SAML:

1) Specify you are using Ping/Okta/Sailpoint and everyone else has to interop.

2) Support ADFS and Shibboleth (as suggested by someone else further down
here) and tell everyone else they have to conform.

------
sigsergv
Unfortunately every enterprise-level SAML server implementation has critical
incompatibilities with the others. So you need to support specific servers and
that's a lot of work and testing.

~~~
orev
I have integrated as an SP with a number of different IdPs and have yet to run
into any problems. For the number of players in the space, it’s remarkably
compatible.

~~~
zrail
Same (author of the OP here). Every IdP is slightly different, but at this
point adding a new one is just importing their certificate and checking the
right boxes (GET/POST, IdP vs SP initiation, etc).

------
blackoil
Isn't this standard for enterprise edition of all SaaS. SAML, Audit log, SLA
and `contact us` pricing.

------
AlphaWeaver
Why did this submission jump from 265 votes to 15 votes?

~~~
foota
Vote ring detection seems like the most likely answer?

edit: but this is just purely speculation based on it being the only way I
know of for a post on hn to decrease in votes.

------
oliyoung
Amazon's Cognito makes this super simple - I only learnt this last week
because AWS' naming schema is so wonderfully opaque

------
pvelagal
Enterprises , especially the big ones would typically have already made
significant investments regarding authentication systems and processes. From
that perspective,it is not fair to ask them to conform to any service specific
authentication models/ processes.

~~~
icebraining
I don't see how fairness even applies. It's a negotiation; you support their
protocol if you get enough in exchange. And sometimes what they offer is not
worth it.

------
LoungeFlyZ
Why try to implement SAML yourself when you could more simply integrate with
something like Office 365 with OAuth and let them do the SAML integration with
the customers Idm system?

~~~
icebraining
If the client doesn't already use Office 365, doesn't that impose the burden
on them to integrate their Idm with it, plus an extra cost per user?

Seems like you're just adding extra costs to your solution, which will weight
against you during the negotiation.

~~~
LoungeFlyZ
the key word is "like". I certainly wouldn't mandate moving the customer to
365 just for this. But chances are they are already using something "like"
Office 365 or Google and have already done the Idm integration.

~~~
icebraining
Fair enough. In my experience, they aren't (that's mostly SMBs, not big
enterprise), but maybe the market is different there.

------
sitepodmatt
Would this imply end user having to have a SAML server on the public internet?
I'd guess big companies would be wary about this

~~~
jcims
Not necessarily. Both the customer-side component (IdP) and SaaS-side
component (SP) just have to be reachable by the client. If the customer org
has its clients on a private network, SAML can function just fine without
being accessible from the Internet. Just put the IdP on the private network
and the SaaS can run anywhere the client can reach.

Look up SAML ‘profiles’ to see the flows. There are exceptions to the above
but they are rarely required.

~~~
tonyarkles
I'm just in the process of setting that up right now! We're on the SP side,
and the IdP lives inside an enterprise network and is not externally
accessible. The only problem is that it's a bit tricky to debug, since they
won't give us VPN access at all. Debugging involves picking up the phone,
asking our contact to do a login, and watching the log messages. Slow, but it
works and it's a big enough contract that it's clearly worth it.

