SAML and SCIM are two-sided protocols. You implement your side, and your customer uses an identity provider (“IDP”) to implement theirs. The problem is that real IDPs are complicated, and usually expensive, to set up. DummyIDP is a simplified IDP that speaks the SAML and SCIM protocols the same way commercial IDPs do, while being far easier to configure.
That means you can test your integration end-to-end from your customer’s perspective, without signing up for a commercial IDP.
There is also a machine-readable version of these docs at /llms.txt.
A DummyIDP app lets you manage a list of users, log in as those users over SAML, and optionally sync that list over SCIM.
To create one, go to the home page and click “Create app”. Every app gets a URL of the form /apps/<app id> that you can return to at any time.
DummyIDP stands in for your customer’s identity provider, so it provides the SAML settings you would normally have to get from your customer:
Every app also exposes an IDP Metadata URL, which is the standard way to distill all three of the above into a single file. Configure your application with either the metadata URL or the three settings individually.
When you implement SAML, your application is the SAML “Service Provider” (“SP”). SP settings are assigned by your application, and your customer would normally enter them into their identity provider. Here, you enter them into DummyIDP:
You are ready to simulate a login once you have:
Then click “Simulate SAML Login”. On that page you choose which user DummyIDP should log you in as. The available users come from the app’s users settings.
DummyIDP also supports SP-initiated login: POST a SAMLRequest to the app’s IDP Redirect URL and DummyIDP will take you to the same login page, carrying the request through so the resulting assertion includes the correct InResponseTo value.
The IDP and SP settings above configure SAML. You can also use DummyIDP to test SCIM. To do that, copy two settings from your application into DummyIDP:
These take effect immediately. As soon as you save them, DummyIDP sends live SCIM HTTP requests to that base URL to sync over every user configured on the app. From then on, any change to the app’s users settings is synced over SCIM straight away, so point this at a test environment rather than anything you care about.
The sync is deliberately stateless, which mirrors how several commercial IDPs behave: for each user, DummyIDP filters /Users by userName, then issues a PUT if a match exists and a POST if it does not. Users that are no longer on the app are deleted. DummyIDP never stores the remote user IDs between syncs.
Every app has a list of users, each with an email, first name, and last name. You can add, edit, or remove them at any time.
This list determines the dropdown when you simulate a SAML login, and what gets synchronized over SCIM if SCIM is configured.
Use DummyIDP to test your SAML and SCIM support. Do not use it to run your business.
Real identity providers implement SAML and SCIM in service of their actual purpose: acting as the authoritative record of who works at an organization and what they can access. DummyIDP does not do that, and is not trying to.
There is no concept of logging in to DummyIDP itself. Anyone with a link to an app can edit its SAML, SCIM, and users settings. There are no private apps — assume every app is publicly editable.
The signing key is published in the source code on purpose, so anyone can mint a valid-looking assertion for any app. That is fine for a test IDP and unacceptable for anything else. Do not connect a DummyIDP app to anything sensitive.