# DummyIDP

> DummyIDP is a fake SAML and SCIM identity provider ("IDP") for testing. It
> implements the IDP side of both protocols so you can test your application's
> Service Provider side end-to-end, without setting up a commercial IDP.

Human-readable version of this document: https://dummyidp.net/docs

## Key facts

- No accounts, no login, no tenancy. Anyone holding an app's URL can edit it.
- An "app" is the unit of configuration: a list of users plus SAML and SCIM
  settings. Apps are long-lived; return to `/apps/<app id>` any time.
- The SAML signing private key is published in the source on purpose. Anyone can
  forge an assertion for any app. This is a test tool, not an auth system.
- Assertions are signed in the browser, and delivered by a real form POST to the
  configured ACS URL.
- Assertion validity is deliberately wide: `now - 1h` to `now + 1h`.

## Creating an app

Go to https://dummyidp.net/ and click "Create app". You get an app ID of the
form `app_<lowercase ulid>` and a settings page at `/apps/<app id>`.

## IDP settings

DummyIDP stands in for your customer's identity provider and assigns:

- IDP Entity ID: `https://dummyidp.net/apps/<app id>`
- IDP Redirect URL (SSO endpoint): `https://dummyidp.net/apps/<app id>/sso`
- IDP Metadata URL: `https://dummyidp.net/apps/<app id>/metadata`
- IDP Certificate: downloadable from the app settings page

Configure your application with either the metadata URL or the individual
values. The metadata URL returns standard SAML 2.0 `EntityDescriptor` XML and
advertises both HTTP-POST and HTTP-Redirect bindings.

Note that SAML entity IDs are opaque, stable identifiers rather than resolvable
URLs. Do not expect to be able to fetch the entity ID.

## SP settings

Settings your application assigns, which you paste into DummyIDP:

- ACS URL (Assertion Consumer Service URL) — where the assertion is POSTed
- SP Entity ID — becomes the assertion's `Audience`

## Simulating a SAML login

Prerequisites: an app exists, its IDP settings are in your application, and your
application's SP settings are in the app.

- IDP-initiated: open the app and click "Simulate SAML Login", then pick a user.
- SP-initiated: POST a `SAMLRequest` to the IDP Redirect URL. DummyIDP converts
  the POST binding into a redirect to its login page, preserving `RelayState`
  and extracting the AuthnRequest `ID` so the response carries the correct
  `InResponseTo`.

Assertion attributes are `firstName` and `lastName`; the `NameID` is the user's
email, with format `urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress`.

There is also `/instant-setup`, a GET endpoint that upserts an app and redirects
straight to its login page. Query parameters: `appId`, `spAcsUrl`, `spEntityId`,
`email`, `firstName`, `lastName`.

## SCIM settings

Two values, copied from your application into DummyIDP:

- SCIM Base URL
- SCIM Bearer Token

Saving these takes effect immediately: DummyIDP begins sending live SCIM HTTP
requests to that base URL. Point it at a test environment.

The sync is stateless. For each configured user, DummyIDP filters
`GET /Users?filter=userName eq "<email>"`, then `PUT /Users/<id>` if a match is
found or `POST /Users` if not. Users removed from the app are deleted with
`DELETE /Users/<id>`. Remote user IDs are never persisted between syncs. Both
`Resources` and `resources` casing are accepted in list responses.

Any later change to the app's users is synced over SCIM immediately.

## Users settings

Each app holds a list of users with an email, first name, and last name. This
list drives both the login dropdown and what is synchronized over SCIM.

## Security posture

Use DummyIDP to test SAML and SCIM support. Do not use it to run a business, and
do not connect it to anything sensitive. Assume every app is publicly editable
and that anyone can forge an assertion for it.