# pysaml2 implements the SAML 2.0 standard in pure Python

> pysaml2 is IdentityPython's implementation of SAML Version 2, containing the pieces needed to build either a service provider or an identity provider, with examples of both. It suits teams that need enterprise federation without writing XML signature handling themselves.

**IdentityPython/pysaml2** — Python implementation of SAML2

- Repository: https://github.com/IdentityPython/pysaml2
- Stars: 616 · Forks: 479
- Language: Python
- License: Apache-2.0
- Published: 2026-10-22 · Updated: 2026-10-22 · Language: en
- Canonical page: https://hysenlabs.com/projects/identitypython-pysaml2

## One library covering both sides of the federation relationship

pysaml2 is a pure Python implementation of the SAML Version 2 Standard, and it contains all the necessary pieces for building either a SAML2 service provider or an identity provider, with the distribution including examples of both. That symmetry is the reason to pick a library rather than a single-sided tool. A service provider consumes assertions that an identity provider has issued, an identity provider issues them, and the two sides of a deployment usually have different teams and different lifetimes. One library that implements both means the assertion parsing and the assertion generation agree on the details, including the parts of the specification that are easy to get subtly wrong, such as the conditions on an assertion and the format of the subject. It was originally written to work in a WSGI environment, and there are extensions that let you use it with other frameworks. The audience is developers building federation into a Python application, typically a service provider that needs to accept enterprise logins, and the project belongs to IdentityPython, a community around libraries and tools for identity related concepts in Python.

## The specification surface it covers, and where it stops

The project documentation lists the specifications it implements, pulled from the OASIS wiki, and the list is where you can see both its reach and its limits. For SAML V2.0 it covers the Core specification with its assertion and protocol schemas, the Bindings, the Profiles, and the Metadata specification with its schema, plus the Authentication Context, the Conformance Requirements, the Security and Privacy Considerations and the Glossary. Beyond the core it also lists a set of profiles and extensions, including the metadata extension for query requesters, the metadata interoperability profile, the metadata extensions for login and discovery user interface, the LDAP and X.500 attribute profile, and the enhanced client or proxy profile, plus a committee specification for subject identifier attributes. The practical reading is that this is a thorough implementation of the SAML 2.0 core, not a narrow subset, and that the extensions a mid sized identity provider is likely to encounter are addressed. What is not on the list is anything about SAML 1.1, and the project's own topics name saml, saml2 and federation. If your partner is still speaking a pre 2.0 dialect, this is not the library for it.

## Installation needs the xmlsec binary, not just pip

The Python side of the install is a single command:

```shell
pip install pysaml2
```

The part that catches people out is the external dependency. PySAML2 works with the xmlsec binary, and support for xmlsec 1 1.3 was added with version 7.4.2, which is a useful detail to know when you hit a signature validation error and suspect the library rather than your system library. The documentation notes that xmlsec should be readily available in most Linux distributions and lists the commands for the common ones:

```shell
$ apt-get install xmlsec1
$ dnf install xmlsec1-openssl
$ yum install xmlsec1-openssl
$ pacman -S xmlsec
```

On macOS it goes through homebrew:

```shell
$ brew install libxmlsec1
```

The declared Python dependencies give a sense of the shape of the thing. cryptography at 46.0.5 or newer, defusedxml, pyopenssl at 26.0.0 or newer, python-dateutil, requests in the 2.x range, and xmlschema in the 2.x range. defusedxml and xmlschema are the two worth pausing on, because a SAML library parses XML supplied by strangers, and the presence of a hardened XML parser and a schema validator in the dependency list is a statement about how the project treats that.

## Console entry points and the metadata tooling

The package installs a set of command line tools, and they hint at what the library is for. make_metadata builds metadata for an entity, mdexport exports metadata, merge_metadata combines metadata documents, and parse_xsd2 parses XSD files. Metadata is the part of SAML that is operationally painful, because every participant in a federation has to publish a metadata document describing its entities, its certificates and its endpoints, and those documents have to be exchanged and kept current. A library that ships the tooling for generating and merging them removes a surprising amount of tedium from an integration. The repository layout is consistent with a project that takes its own testing seriously. There is an example/ directory with a runnable set of scenarios: an idp2 example, a sp-wsgi example, an sp-repoze example, an idp2_repoze example, an attributemaps directory, a requirements.txt, an all.sh script and a create_key.sh helper, and the create_key script name is itself a hint that generating and handling keys is a first class part of the workflow. The s2repoze optional dependency group with paste, repoze.who and zope.interface exists precisely so that the WSGI original and the repoze.who style integration are both installable.

## A working example, and a way to exercise the deployment

The repository ships example projects that are meant to be run rather than read, and that is the fastest way to understand the model. The example/ directory contains an idp2/ directory for the identity provider side, sp-wsgi/ for a service provider running under WSGI, sp-repoze/ and idp2_repoze/ for the repoze.who variants, plus attributemaps/ and the shell helpers all.sh and create_key.sh. Running the examples locally gives you a real federation to test against, and a testing pair is a much better tool for confirming that your metadata, your certificates and your bindings are correct than a single working deployment is. The project also has a testing story for itself, with a tests/ directory, a script/ directory, a pyproject.toml that configures the build, and a poetry.lock, plus a .travis.yml for continuous integration. Development tooling is thorough for a library at this age: black and isort for formatting, tox, flake8 with a stack of plugins including bugbear and logging-format, mypy, and ipdb. There is a DEVELOPERS.md, a CONTRIBUTING.md, a separate RELEASE.md describing the release process, a SECURITY.md for reporting security problems, and a CHANGELOG.md that the documentation points to for the latest developments.

## Where pysaml2 is the wrong choice

The first limitation is scope of protocol. This implements SAML 2.0 and nothing else, so a deployment whose identity provider speaks only OpenID Connect gets no help from it, and modern consumer facing applications increasingly do. The second is that SAML is not simple, and the library does not make it simple, it makes it possible. A production deployment involves certificate and key management, metadata publication and distribution, clock synchronisation between the two parties, and careful handling of the binding and signature validation rules. The examples help you get a federation running locally, but the hard part of SAML is the operational discipline around it, and that discipline is not in the library. The third is the dependency on a native binary. xmlsec is a C library that has to be present and correctly linked, and in a container that means either a base image with it installed or a build step, and in some locked down environments a native library is simply a burden you would rather not take on. A different approach, if you control both ends of the relationship, is to use OpenID Connect with a library that is pure Python and has no external binary, since the specification is designed for clients that are not browsers. The trade is that you lose the installed base of enterprise identity providers that speak SAML, which in a corporate context is the whole point. A fourth consideration is that the project is a mature, community run library with a long history, and the pace of work is what a volunteer community sustains rather than what a vendor guarantees, so if you need contractual support you need a different arrangement.

## Conclusion

Adopt pysaml2 if you need to speak SAML 2.0 from Python, either as a service provider consuming assertions or as an identity provider issuing them, and you can install the xmlsec binary and manage the keys and metadata that SAML requires. Do not adopt it for an OpenID Connect only deployment, since it implements SAML 2.0 and nothing else. Before you build on it, read the security policy in SECURITY.md and the changelog, confirm the xmlsec version you install is one the library supports, and plan for the metadata and key distribution work, which is usually more of the effort than the library itself.

## FAQ

### What is pysaml2?

It is IdentityPython's pure Python implementation of the SAML Version 2 Standard, containing all the pieces needed to build a SAML2 service provider or an identity provider, with examples of both included in the distribution. It was originally written to work in a WSGI environment, with extensions for other frameworks.

### What extra dependencies does pysaml2 need?

It works with the xmlsec binary, and support for xmlsec 1 1.3 was added with version 7.4.2. The Python dependencies are cryptography, defusedxml, pyopenssl, python-dateutil, requests in the 2.x range and xmlschema in the 2.x range, with an optional s2repoze group for paste, repoze.who and zope.interface.

### How do I install pysaml2 and its system dependency?

Install the library with `pip install pysaml2`, then install the xmlsec binary for your platform, for example `apt-get install xmlsec1` on Debian and Ubuntu, `dnf install xmlsec1-openssl` on Fedora, `pacman -S xmlsec` on Arch, or `brew install libxmlsec1` on macOS.

### Does pysaml2 support SAML 1.1?

The documented specification coverage is SAML V2.0, covering Core, Bindings, Profiles, Metadata, Authentication Context and the listed profiles and extensions. SAML 1.1 is not part of the documented scope, so a deployment with a pre 2.0 identity provider is outside what this library covers.

### What tools does pysaml2 ship for metadata?

The package installs console entry points including make_metadata, mdexport, merge_metadata and parse_xsd2. The example directory also contains runnable identity provider and service provider scenarios, including sp-wsgi, sp-repoze and idp2_repoze variants, plus a create_key.sh helper.

## Sources

- [IdentityPython/pysaml2 on GitHub](https://github.com/IdentityPython/pysaml2)
- [Issues](https://github.com/IdentityPython/pysaml2/issues)
- [License: Apache-2.0](https://github.com/IdentityPython/pysaml2/blob/master/LICENSE)
- [README](https://github.com/IdentityPython/pysaml2/blob/master/README.md)
- [Releases](https://github.com/IdentityPython/pysaml2/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/identitypython-pysaml2