SAML Single Sign-On
Let organizations control app access through their own identity provider.
What it adds
SAML SSO configured per organization, with attribute mapping, certificate rotation, and a break-glass login.
What your agent is told to do
7
What your agent is told to do
7-
1
Configure SSO per organization, not globally. Two customers will have different providers, certificates, and attribute names.
-
2
Validate every assertion fully: signature against the configured certificate, issuer, audience, destination, and the not-before and not-on-or-after window. An assertion that fails any of these is rejected, not repaired.
-
3
Reject replayed assertions by recording assertion IDs for the length of their validity window.
-
4
Map identity provider attributes to app users by a stable identifier the provider guarantees, and only accept role or group claims that you have explicitly mapped in the app's own configuration.
-
5
Support two active signing certificates at once so a customer can rotate without a window of downtime.
-
6
Keep at least one break-glass administrator who can sign in without SSO, and audit every use of it. A misconfigured provider otherwise locks the whole organization out of the tool they need to fix it.
-
7
Do NOT trust anything in the assertion to grant privileges it was not mapped to — self-asserted admin claims are the classic SAML escalation.
Edge cases it handles
7
Edge cases it handles
7- Clock skew between provider and app must be tolerated by a small fixed margin only, never by disabling time checks.
- An expired certificate must produce an actionable admin error and a warning ahead of expiry, not a generic login failure.
- Enforced SSO must decide what happens to existing password and OAuth logins for that domain: disable them, and say so before enforcement starts.
- Just-in-time provisioning must not create users outside the organization's verified domains.
- A user removed at the identity provider keeps their app session until it expires — revoke sessions on de-provisioning rather than relying on the next login.
- Identity-provider-initiated sign-in arrives with no local request to match; support it explicitly or reject it explicitly, and pick a safe landing destination.
- Encrypted assertions, signed responses, and signed assertions are different configurations — handle whichever the customer sends rather than assuming one.
Definition of done
8
Definition of done
8- SSO is configured per organization with its own metadata and certificates.
- Signature, issuer, audience, destination, and time window are all verified on every assertion.
- Replayed assertions are rejected.
- Two signing certificates can be active at once, so rotation causes no outage.
- Only explicitly mapped claims affect roles or permissions.
- A break-glass administrator login exists and every use of it is audited.
- The feature matches the existing design system.
- No existing functionality is broken.
Related features
Upload Malware Scanning
Upload Malware Scanning
Quarantine uploaded files until they are known safe.
What it does
A quarantine lifecycle for uploads: every new file is unreachable until scanned, with defined handling for scanner failures and infected results.
How it works
- 1 Give every upload an explicit scan state — pending, clean, infected, or error — and default it to pending the moment the bytes land.
- 2 Make pending and infected files unreachable from every access path in the app, including admin views, previews, thumbnails, and any signed URL. A quarantine with one exception is not a quarantine.
- 3 Scan asynchronously and update the state; do not block the upload request on the scanner.
Copy the prompt
No account needed
Add this feature to my app:
https://addthisfeature.com/x/upload-malware-scanning
Rate Limiting
Rate Limiting
Stop one client from ruining it for everyone.
What it does
Throttling on the endpoints that get abused: auth, search, exports, and public forms.
How it works
- 1 Identify the endpoints worth protecting: sign-in, sign-up, password reset, search, exports, and anything unauthenticated.
- 2 Limit by a stable identifier — user ID where signed in, IP otherwise. Be aware IP is shared behind NAT and proxies.
- 3 Return 429 with a Retry-After header. Do not silently drop the request.
Copy the prompt
No account needed
Add this feature to my app:
https://addthisfeature.com/x/rate-limiting
Password Generator
Password Generator
Offer a strong password in one click wherever someone sets or changes credentials.
What it does
A generate control on password fields that produces a strong value, shows it, and hands it to the user safely.
How it works
- 1 Add the control to every place a password is set: sign-up, password change, password reset completion, and any admin screen that provisions credentials for someone else.
- 2 Generate the value in the browser using the platform's cryptographic random source. The value must never be produced on the server or sent anywhere.
- 3 Reveal the generated password by default so the user can record it, and offer a regenerate control beside it. A hidden generated password that the user cannot see is a password they will immediately reset.
Copy the prompt
No account needed
Add this feature to my app:
https://addthisfeature.com/x/password-generator
How it works
-
1
Copy the link
Grab the Markdown instruction URL for this feature.
-
2
Give it to your AI
Paste it into Claude Code, Cursor, v0, Lovable — whatever you build with.
-
3
It inspects, then implements
Your agent reads your existing app first, then adds the feature to fit it.
Works with your stack
These instructions are written to adapt. They tell the agent to detect your framework, match your existing design system, and reuse what you already have — rather than assuming a particular stack.
Need it tighter than that? Customize the feature and tell it exactly what you're running.