Sustainsys.Saml2 makes an ASP.NET app a SAML2 service provider

One library, one role: the site becomes the service provider

The library's stated job is narrow and precise. Sustainsys.Saml2 adds SAML2P support to ASP.NET web sites, allowing the web site to act as a SAML2 Service Provider. That is the whole scope, and understanding it saves time. The library is not an identity provider, it does not issue assertions, and it does not store users. It consumes the SAML2P protocol so that an external identity provider can authenticate a user and hand the result to your application, which then protects that application with the resulting identity. The name changed at some point, since the README notes the library was previously named Kentor.AuthServices, so older code and older blog posts will refer to a different package and a different namespace.

Three branches with different support promises, and a fourth kept for links

The branch structure is where the practical decisions live, and the README is unusually clear about it. The `main` branch is the version in active development, currently v3, and it only supports ASP.NET Core. The `v1` branch is a supported version that uses the `System.IdentityModel` library for token handling and supports HttpModule, Mvc, Owin and AspNetCore2, the last only on full .NET Framework. The `v2` branch is a supported version that uses the `Microsoft.IdentityModel` nuget packages for token handling, multi-targets, and also supports HttpModule, Mvc, Owin and AspNetCore2. Both v1 and v2 receive only security fixes or critical compatibility fixes for major browsers. There is also a `master` branch, deprecated and kept only so that old links pointing to it still work.

New features on v2 are reserved for paying customers

One clause in the branch description is easy to skim and important to plan around. The v1 and v2 branches get security fixes and critical browser compatibility fixes, and the README adds that exceptions for new features can also be done for paying customers with support contracts. So the v2 line is not a frozen branch, it is a branch where the default path is maintenance and the default answer to a feature request is no unless there is a commercial relationship. The same theme runs through the section on commercial options. The maintainer explains that running an open source library takes time, that the issue and pull request list constantly needs work to keep it clean, that bug reports of possible security vulnerabilities need to be evaluated even when they turn out to be incorrect, and that any pull request to a security library needs careful evaluation. He says the commercial model has partly succeeded but not to the extent that he can spend the time he wants on the library.

What the v3 rewrite is trying to become

The development goals section gives the clearest picture of where the library is going, and it is a rewrite of the plumbing rather than a new feature set. The goals are to get a new, more flexible architecture. Reading XML is to be done with more strict validation, but found errors can be suppressed, which is a deliberate trade between refusing malformed assertions outright and letting a caller decide. The Asp.Net Core RemoteAuthenticationHandler is to be used as a base class, which moves the library onto the framework's own authentication pipeline instead of its own handler model. Support for the AspNet Core configuration system is listed as a goal, and the last item is that federations will become their own authentication handler type, with the README contrasting `builder.AddSaml2` against `builder.AddSaml2Federation` as the shape of that split.

Where to read the usage details and where to find working code

The README is not a usage guide, and it says where the usage guide is. Documentation is at the Sustainsys documentation site, and the README points there rather than duplicating setup steps. For code, there are samples in the `v1` and `v2` branches, and newer samples live in a separate Saml2.Samples repository. That arrangement is worth noting for a security library, because it means the sample code you read may not match the branch you are on. A new project on ASP.NET Core should start from the v3 work on `main` and from the newer samples repository, while a team pinned to an older framework is working from a branch where the samples have to match the branch's own era. The repository root also carries a SECURITY.md and a LICENSE.txt alongside a LICENSE_MIT.txt, so the licensing position is defined in files rather than in a badge.

Version history that reads like a changelog of security concerns

The release tags give you the priorities of the maintainer over time without needing to read the commits. v2.9.2 came out on 2023-09-19 with no descriptive note attached. v2.10.0 on 2024-08-09 is labelled FIPS Compliance, and v2.11.0 on 2025-03-02 is labelled Encrypted XML enhancements. Both of those are the kind of work that matters specifically for a SAML library: a protocol whose payload is signed XML needs to be able to handle encrypted assertions, and organisations with compliance requirements need the cryptographic pieces to fit a FIPS boundary. The last push to the repository was on 2026-05-21, so the v3 work is still moving. The v2 line is what most existing deployments are on, and the v2 releases are where the crypto and compliance features landed.

The alternative is a hosted identity provider, and the trade is who owns the flow

The realistic alternative to this library is not another SAML2 package but a different architectural choice: letting a hosted identity service own the sign-in flow, so your application receives an identity through a redirect rather than implementing the SAML2P exchange itself. The difference in approach is concrete. A service provider library keeps the protocol inside your application, so the assertion handling, the metadata configuration and the request validation live in your process and in your release cycle, and a change to the identity provider's metadata is something you deploy. A hosted identity service moves the protocol to the provider, so your application ends up with a simpler callback contract but a dependency on an external service and on its configuration. Which one you want comes down to whether the identity relationship is something you can outsource. If it cannot be, if a compliance boundary sits between you and the identity provider, or if the deployment environment rules out a third party redirect, then implementing the service provider role locally is the choice, and that is what this library is for.

Editorial conclusion

Sustainsys.Saml2 fits a team running ASP.NET that needs to act as a SAML2 service provider against an existing identity provider, and that wants to stay on a maintained branch rather than a hosted identity product baked into the app. It does not fit a team on .NET Framework 4.x MVC or HttpModule, since the v1 and v2 branches are limited to security and critical browser compatibility fixes, and it does not fit anyone who expects a stable v3. Before you choose a branch, read the branch notes in the README, check whether your hosting is ASP.NET Core, and plan for the migration to the RemoteAuthenticationHandler based architecture that main is heading towards.

Frequently asked questions

Official sources

1. Issues
2. README
3. Releases
4. Sustainsys/Saml2 on GitHub