Why your SaaS application should support SAML(petekeen.net)
petekeen.net
Why your SaaS application should support SAML
https://www.petekeen.net/why-your-saas-application-should-support-saml
31 comments
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.
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.
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.
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.
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.
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.
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/
[1]: https://adodson.com/hello.js/
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.
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.
A not-encrypted assertion over https makes sense, but not signed?!?!?
> but not signed
That's right... Key management is hard lets go ride bikes.
That's right... Key management is hard lets go ride bikes.
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.
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.
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.
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.
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.
Surely, in practice, you support ADFS and Shibboleth, and then you implement additional support as your clients ask it of you.
If you're doing it the Microsoft way, you throw up your own instance of ADFS, configure that to authenticate against your clients' SAML IDPs, and authenticate against your own ADFS yourself, thus avoiding having to deal with interop concerns within your own application. Practically everybody can interop with ADFS. On non-Microsoft systems, I believe the likes of OpenAM (or its paid-for version, ForgeRock Access Management) can do this, among other options.
If you're doing it the Microsoft way, you throw up your own instance of ADFS, configure that to authenticate against your clients' SAML IDPs, and authenticate against your own ADFS yourself, thus avoiding having to deal with interop concerns within your own application. Practically everybody can interop with ADFS. On non-Microsoft systems, I believe the likes of OpenAM (or its paid-for version, ForgeRock Access Management) can do this, among other options.
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.
Isn't there some (e.g. NodeJS) library for that?
Isn't this standard for enterprise edition of all SaaS. SAML, Audit log, SLA and `contact us` pricing.
Why did this submission jump from 265 votes to 15 votes?
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.
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.
Amazon's Cognito makes this super simple - I only learnt this last week because AWS' naming schema is so wonderfully opaque
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.
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.
What is sunk cost is irrelevant.
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?
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.
Seems like you're just adding extra costs to your solution, which will weight against you during the negotiation.
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.
Fair enough. In my experience, they aren't (that's mostly SMBs, not big enterprise), but maybe the market is different there.
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
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.
Look up SAML ‘profiles’ to see the flows. There are exceptions to the above but they are rarely required.
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.
In our case, it was the opposite: the SaaS (for that client) was not on the public Internet. The client reserved some machines on their DC and we set up a private installation there.
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.