It’s pretty tough to navigate the landscape of SAML authentication. Developers, product managers, and security/IT leaders often complain to us that no one seems interested in making SAML easy. I hope that this resource plugs at least some gaps.

First, a quick mea culpa: I had a pretty low quality placeholder post on this URL for a few months. I put it up, planning to improve it, and then I got distracted. Our business started growing quickly, and a few things fell off my to-do list. This page has itself started getting a lot of traffic, so I’m scrambling to make it a good resource. Sorry about that. I didn’t mean to make crappy clickbait!

Please consider this a work-in-progress. It’s definitely not done yet – it may never be done. So if you think I’m missing anything important, or if you think I’m flat-out wrong about something, please drop me a note at ned.oleary@ssoready.com. I’m often wrong about things and am always grateful for the input.

So what exactly is a SAML implementation?

Before we get deeper into this, we need to clarify that we can mean different things when we’re talking about “a SAML implementation.”

Almost without exception, we’re talking about SAML single sign-on (SSO) for web applications. (If you’re using SAML for something else, please email me… you’re doing something unusual, and I want to learn about your use-case.)

In SAML single sign-on, we have a few different entities that get involved. We have:

An end-user – a person that wants to use a certain web application
A service provider (SP)– the web application that the user wants to access
An identity provider (IDP) – software controlled by the user’s employer (or some other organization, e.g., a university) to control users’ access to different web applications

Exactly how these entities interact doesn’t suit the scope of this post. If you’re unsure about the distinction between an SP and an IDP in SAML, you should read one of these posts that we put together:

A gentle introduction to SAML: a simplified overview of SAML for someone that’s just getting started
SAML, a technical primer: a pretty comprehensive practical explanation of everything a typical developer would need to know about SAML

There’s an additional entity we need to cover. Most developers find SAML really challenging (or tedious, or unreasonably time-consuming), and so they often use a third-party service to stand in the middle and handle communications with identity providers. From here on, we’ll call these identity brokers.

(Our company, SSOReady, makes one such middleware service that you can consider if you need to become a SAML service provider. If you’re interested in how it works, you can read our documentation here.)

In order, we’ll cover:

A list of major open source SAML identity providers (IDPs) – services that are relevant to corporate security/IT teams for workforce authentication
A list of major open source SAML identity brokers – services that are relevant to software developers that want to implement SAML as soon as possible
A list of some SAML libraries – a variety of tools that a resourceful developer can adapt to hack together a SAML implementation

Apologies for the long winded exposition. I can’t help myself sometimes.

List of open source SAML implementations

Open source SAML identity providers

The landscape for open source SAML IDPs isn’t great. You’ll have a few options, but there aren’t a lot of great ones.

In most organizations that need a workforce identity product with SAML SSO, it’s probably best simply to use a commercial SaaS. It’s just not that common to need anything especially sophisticated, these products aren’t that expensive, and it’s often helpful to offload the maintenance burden to a proven vendor. Common commercial IDPs include Microsoft Entra ID, Okta, OneLogin, and JumpCloud.

The closest analogue to closed source commercial IDPs that I’m aware of is Authentik.

Shibboleth as a SAML IDP (link)

The Shibboleth Consortium makes a couple of different products. They’ve been around for more than 20 years.

Their identity provider product is most commonly used in higher education, e.g. at UChicago, Stanford, and Oxford. The product really does work – I’ve used it myself. It comes with compatibility for some less popular features, e.g. single sign-on via CAS. It has decent documentation. It works really nicely with Windows. Most importantly, though, Shibboleth’s probably not going anywhere.

At the same time, Shibboleth’s a little bit clunky both for end users and for deployment. There’s a bit of a weird maze of dependencies you’ll have to navigate at the start. Honestly. It is not easy to get Shibboleth working. I think this challenge shows in The Consortium’s relative lack of growth over the past few years.

If you’re a big, well-resourced organization looking for a proven solution for the long haul, Shibboleth is likely a good option. It’s really not a fit if you’re looking for something simple. In either case, I’ll urge you to consider hiring a consultancy to handle your implementation.

Authentik as a SAML IDP (link)

Authentik’s a pretty new player. The project has existed since 2018, and the company now behind Authentik has only been around since 2022.

Here’s what’s really great about Authentik: you can spin up an Authentik instance on localhost in 2-3 minutes. It really is easy to get started.

They’re also pretty transparent and seemingly committed to open source. Like us, they’ve put their product on an MIT license and have made the enterprise product source-available.

Authentik has all of the core features you’d normally want. You can get SAML, SCIM, and OAuth. You can get identity federation support. It also comes with some extras like authentication flows and policies. I’m not entirely sure whether they’ve built out every enterprise feature you could reasonably need. It’s not the most simple product in the world – it feels like it’s been built for relatively technical users – but it’s not too overwhelming either.

If you’re a developer, it’s probably a solid option!

Keycloak as a SAML IDP (link)

Keycloak’s an open source project from the Cloud Native Computing Foundation, which is a Linux Foundation project. It’s been around since 2014, and it’s become relatively well-known among developers.

Like Authentik, it’s pretty easy to get started with Keycloak via Docker. It’ll nudge you into a simple onboarding flow that makes you set up some users, and you’re done within a few minutes.

Keycloak comes with the features you’d expect. You can use Keycloak for single sign-on via either Open ID Connect (OIDC) or SAML. You can use it for identity federation. Keycloak comes with some nifty AD/LDAP support, meaning you can pull user data in from different directories that you might be using.

This is definitely a product for developers. Keycloak has its strengths, but it’s not the most intuitive product (not that many commercial IDPs are themselves especially intuitive). The project has decent documentation, although there’s some room for improvement. Whoever’s responsible for keeping Keycloak running probably needs a decent amount of technical skill (and time). It’s something to bear in mind if you’re planning on using this for a business.

SimpleSAMLphp as a SAML IDP link

SimpleSAMLphp’s an open source project that you can use as a SAML IDP. It also has a few trusted consulting partners that can layer on commercial support.

I haven’t personally used SimpleSAMLphp, and I haven’t gotten firsthand feedback from anyone who has. It’s pretty clear from the documentation that this project isn’t for everyone. Do not treat SimpleSAMLphp as a substitute for a friendly, out-of-the-box web application like Okta or Jumpcloud.

This is a great project for unusually curious or confident people. If you’re an experienced security engineer building a full-fledged identity provider, for instance, it might be a good option. A decent number of IDP projects rely SimpleSAMLphp to handle their SAML. For example, a commercial open source project called Univention Corporate Server uses SimpleSAMLphp.

Deprecated: ForgeRock OpenAM as a SAML IDP (link

Forgerock used to maintain an open source IDP. It’s a dead project now. The last commit that I can find was back in 2017.

If you’re pretty resourceful, you might be able to hack together something that works using OpenAM. I don’t recommend it. It’s really not going to be worth the effort.

Wren Security Suite as a SAML IDP (link)

It seems like a few people in the Czech Republic picked up ForgeRock’s abandoned open source work. They’ve kept up with its maintenance as Wren Security, sponsored by an IAM consultancy called Orchitech.

The project seems alive and well, but the documentation honestly isn’t very thorough. If you’re really patient, you might be able to figure it out. I haven’t myself had the chance to experiment. Practically speaking, you might be better off hiring the Orchitech consultancy.

Open source identity broker implementations – tools that help you become a SAML service provider

There are a few tools you can use to become a SAML service provider, given an existing backend. I’m not going to include tools like Supabase SSO, which provide SAML single sign-on as part of a more comprehensive backend-as-a-service. They’re sometimes a viable option, but they’re not really what I’m covering here.

Keycloak for SAML SPs (link)

You can actually use Keycloak to accept SAML logins! It’s pretty neat. Keycloak offers a lot of flexibility. You can even use Keycloak to show a login page in the user interface of your application.

Here again, though, I wouldn’t consider Keycloak especially approachable. There’s an awful lot that you’ll have to understand to use Keycloak as a SAML intermediary. I don’t personally think it’s the best option, just because it’s kind of tricky.

But let’s be clear – Keycloak works! And it’s undoubtedly the closest thing to a default, at least among open source tools. Tons of real companies use Keycloak.

Zitadel for SAML SPs (link)

Zitadel’s a young company that offers managed authentication products. They contrast themselves against Firebase, Auth0, and Keycloak.

I don’t intend to criticize Zitadel, but I don’t feel that Zitadel is very easy to use or has very clear documentation. I have a hard time figuring out what’s going on sometimes. It seems like they’re aiming to become a spiritual successor to Keycloak – a very powerful product that affords developers a lot of flexibility. That’s an ambitious undertaking, so I’m sympathetic to the chaos that they have to wranlge

I think if you’re pretty experienced with IAM – especially if you’ve used Keycloak before – you might keep tabs on Zitadel’s project. If you’re just getting started and are facing real, practical constraints, you might not find Zitadel to be the right fit.

But I’m open to being proven wrong here! Auth is hard, this is an early stage company, and they have lots of opportunity to really nail the experience. Who knows… maybe next time I revisit this post, I’ll feel differently.

Apache Syncope for SAML SPs (link)

You could try out Syncope. It’s a bit of a holistic enterprise identity management product. It apparently does support SAML logins. I have not used this project myself, so I’ll reserve comments. I’ll just say that Syncope seems to do an awful lot of stuff. If you’re reading a blog post like this, it’s probably not a great fit for you. I don’t personally see significant advantages to using this.

SimpleSAMLphp for SAML SPs (link)

You can use SimpleSAMLphp for a SAML SP implementation, even in non-PHP apps. It’s … not straightforward. As they put it, the path to getting SimpleSAMLphp working in a non-PHP app is “not yet fully documented.” This is another case where you might get it working, but you’re at risk of wasting your time. I don’t personally have the patience.

SSOReady for SAML SPs (link)

This is us! We think we make the easiest-to-use tools to help developers offer SAML SSO in their apps. It’s just two endpoints to start offering SAML logins. People often finish their implementations the same day they start. We put our software on an MIT license. We have a free cloud service at app.ssoready.com Come try it out!

I’d be really grateful for feedback either way.

BoxyHQ for SAML SPs ([link])(https://boxyhq.com/)

BoxyHQs works a bit like SSOReady. Of your options, it’s one of the better ones. I know a decent number of people who rely on BoxyHQ. You’ll get this working without too much trouble.

They’ve done a particularly good job of serving Next.js apps; you can find a NextAuth.js example here.

Framework- or language- specific SAML implementations

You can often find framework- or language-specific tools for SAML implementations – provided, of course, that you aren’t using an unusual tech stack.

Note that these tools generally lag commercial projects in their ease-of-use, quality of documentation, and general maintenance. SAML’s not unlike other tools in that sense.

I’m largely relying on crowdsourcing to establish how useful these are. I don’t have reliable data on breadth of use, and I haven’t tested all of these personally. Please don’t be surprised if you run into issues!

Python SAML libraries for SPs

Python has some of the stronger SAML tooling out there. I haven’t vetted all of these personally –

pysaml2 – seems to be the most commonly used option these days
python3-saml
Flask SAML2
django-saml2-auth

Of course, you could just use our Python SDK instead and save yourself some trouble.

Javascript SAML libraries for SPs

I’m realizing now that I don’t often hear people talk about SAML libraries for Javascript backends. I’m not sure why. Maybe I’m just not having the right conversations.

In any event, these seem to be the most common choices:

As with Python, you could just use our SDK to make your life easier.

Go SAML libraries for SPs

Please be very careful using other people’s SAML implementations in Go. Several years ago, Go’s encoding/xml had some round-trip vulnerabilities, and it’s not always obvious whether a given SAML implementation opens you up to risk.

I understand these to be fairly common options for Go developers:

gosaml2
saml

Alternative: use our SDK. We have a simple example app linked there. SSOReady itself is written in Go. You can check out the source code on our GitHub.

Ruby SAML libraries for SPs

The dominant SAML library for Ruby is is pretty clearly ruby-saml. It’s still used by some pretty big, sophisticated companies. However, make sure you’re aware of its issues with signature wrapping attacks that afflicted companies like NetApp and GitLab. Please make sure you’re using a patched version.

SSOReady makes an SDK you can use instead. We have example apps for Sinatra and Rails.

PHP SAML libraries for SPs

I already mentioned SimpleSAMLphp above, but here are some other options you could try:

Alternative: the SSOReady SDK. We have example apps in vanilla PHP and in Laravel.

C# SAML libraries for SPs

The C# ecosystem seems relatively poorly served wtih SAML libraries. It does seem that Jitbit does a good job maintaining AspNetSaml, which you might find useful.

The default option seems to be ComponentSpace. It’s commercial software, but it’s not SaaS. You can just download the source code if you pay them a little bit of money one time.

Alternatively, you could explore our SDK for ASP.NET core.

Java SAML libraries for SPs

Java generally has some good options for SAML, e.g.:

spring-security – seems to be the most common option these days
java-saml
OpenSAML

We do make a Java SDK too – you can find an example Spring Boot app here.

List of major open source SAML implementations