SI

SimpleSAMLphp

PHP implementation of SAML and identity federation

Identity & SSO ★ 1.1k stars Medium setup LGPL-2.1

SimpleSAMLphp is a widely used PHP application for implementing SAML 2.0 identity and service providers. It enables web single sign-on and federation for PHP environments and beyond.

Key features

  • SAML 2.0 IdP and SP
  • Identity federation
  • Many auth backends
  • Module ecosystem

Pros & cons

Strengths

  • Proven and widely deployed
  • Flexible modules

Trade-offs

  • Configuration is intricate
  • PHP performance limits

SimpleSAMLphp replaces

Last reviewed Sep 13, 2026 · 849 words

Most self-hosters who search for SimpleSAMLphp actually need one of two different things, and the answer differs. If you need a SAML identity provider for your homelab (one login for Nextcloud, Grafana, Gitea), run Keycloak or Authentik instead; both speak SAML and OIDC, ship an admin interface, and are what the 2026 ecosystem assumes. If you need to make a PHP application become a SAML service provider, or you are wiring an institution into an academic federation, SimpleSAMLphp is the tool that has done that job since 2007 and still does it best. It is a library with a web front-end, not a product, and treating it as a product is where the frustration starts.

What it is in the stack

SimpleSAMLphp is a PHP codebase you install with Composer and expose at a path (conventionally /simplesaml/) on a web server. Configured one way, it is an IdP: it authenticates users against a backend and issues SAML assertions to registered service providers. Configured another way, it is an SP: your PHP app calls its API, gets redirected to a remote IdP, and receives attributes back. Many deployments are both, acting as a bridge between an internal LDAP and an external federation. The auth backends are the reason it stuck around: LDAP, SQL, RADIUS, a static password file for testing, OAuth and OIDC modules for logging in through external providers, and multi-factor via modules. The identity category has flashier tools; almost none of them have been in production at universities for well over a decade.

Configuration is PHP arrays, and that is the whole difficulty

There is no admin interface for setup. config/config.php holds the base URL, secret salt, admin password, session storage, and a long tail of other keys. config/authsources.php declares each authentication source as a PHP array. metadata/saml20-idp-hosted.php and metadata/saml20-sp-remote.php hold the IdP's own metadata and each trusted SP's metadata, again as arrays. Every SP you federate with needs its entity ID, assertion consumer URL, and certificate pasted into a file, and every attribute mapping is a manual entry. This is precise, versionable, and merciless. A wrong baseurlpath produces redirect loops that look like a certificate problem, and session storage left on PHP files behind a load balancer produces logins that succeed and then vanish. Read config.php top to bottom once before touching any of it; that hour pays for itself.

The web pages are for debugging, and they must not be public

The /simplesaml/ front page offers a test-authentication page, a metadata viewer, and diagnostics. These are invaluable on day one and dangerous on day two: leave the admin password weak or the diagnostics reachable from the internet and you have published your configuration. Set a strong auth.adminpassword, restrict the admin pages by IP at the web server, and consider hiding the front page entirely once the SPs are configured. The 2.x line tightened a lot of this, dropped legacy modules, and expects Composer, so if you find a tutorial that unzips a tarball into the web root, it is describing an older era.

Performance and the PHP tax

Every SAML exchange is a couple of signed XML documents and a session lookup, so throughput is rarely the issue; a 256 MB PHP-FPM pool handles a small organisation without noticing. The real limits are operational: session storage should be a database or Memcached rather than files if you run more than one web node, and the metadata files grow unwieldy past a few dozen SPs, at which point the metarefresh module (pulling federation metadata automatically) becomes mandatory rather than convenient. The Docker deployment exists, but most production instances are plain PHP on a distribution package or a Composer checkout, which is also where the documentation lives.

When to pick it over the modern IdPs

Three honest cases. Your application is PHP and needs to be an SP: use SimpleSAMLphp as the library; it is the least surprising path. You are joining an academic or governmental federation that ships SimpleSAMLphp examples and metadata feeds: use it, because you will be following their runbook. You already run it and it works: leave it alone. For a new homelab SSO, a new company, or anything where you want OIDC, a user interface, self-service, and modern MFA out of the box, Keycloak is the safer default and the Authelia versus Authentik comparison covers the lighter end.

What I'd do

As a self-hoster, I would keep SimpleSAMLphp out of the IdP role and run Keycloak or Authentik there. I would reach for SimpleSAMLphp when a PHP app I maintain needs to speak SAML to someone else's IdP: install it with Composer, keep the config in git, lock the admin pages to my IP, and test every SP with the built-in authentication page before announcing it. It is mature, LGPL-licensed, and unglamorous, and in the narrow job it was built for, still the right answer.

Compare SimpleSAMLphp

17 head-to-head comparisons.

Similar identity & sso apps