About
Built for teams who take authentication seriously
SAML Manager was built by identity engineers who have spent years wiring together Identity Providers and Service Providers across enterprises. We know that the hardest part isn't the SAML spec — it's safely managing the certificates, API keys, client secrets, and shared credentials that keep those integrations running.
Credential security is not a feature we added at the end. It is the architectural foundation the rest of the product is built on. Every decision — from how fields are transmitted, to how secrets are stored, to who (or what) is allowed to decrypt them — was made with the assumption that the credentials you store here are critical infrastructure.
How Your Credentials Are Protected
Every credential you store in SAML Manager passes through a layered security model. No single failure point can expose your secrets.
-
Client-Side Field-Level Encryption
When you submit a credential, SAML Manager uses AWS CloudFront Field-Level Encryption (FLE) to encrypt the sensitive
credential_datapayload with an RSA public key inside your browser, before the HTTP request is sent. This means the cleartext secret never appears in TLS termination logs, application access logs, WAF logs, CDN caches, error traces, or any other server-side artifact — because the server only ever receives ciphertext. -
TLS 1.2+ End-to-End Transport
All traffic between your browser and SAML Manager is carried over TLS 1.2 or higher with strong cipher suites. Combined with CloudFront FLE, even a hypothetical transport-layer compromise would expose only encrypted data.
-
Application Layer — Zero Plaintext Persistence
The Django application server receives the already-encrypted
credential_datablob. Only non-sensitive metadata — credential name and description — is stored in the application database. The sensitive payload is immediately handed off to AWS Secrets Manager without the application ever decrypting or logging the contents. No ORM field, database column, or query log ever contains a plaintext secret. -
AWS Secrets Manager — First Encryption Layer at Rest
Credentials are stored as secrets in AWS Secrets Manager, which natively encrypts every secret value using envelope encryption backed by AWS KMS. Secrets Manager also handles rotation scheduling, versioning, and fine-grained access control through IAM resource policies — so access to a secret is as narrow as the IAM principal that needs it.
-
AWS KMS Customer Master Key — Second Encryption Layer at Rest
On top of Secrets Manager's native encryption, every secret is wrapped with a dedicated AWS KMS Customer Master Key (CMK) provisioned specifically for your organization. This gives you two independent, fully auditable encryption layers at rest. Compromising Secrets Manager's internal key material does not expose secrets protected by a separate CMK, and vice versa. Every encryption and decryption event against the CMK is logged in AWS CloudTrail, giving you a complete, tamper-evident audit trail.
-
Per-Organization Key Isolation
Each organization in SAML Manager is assigned its own KMS CMK. The key policy scopes decryption rights to the specific per-organization Lambda role responsible for provisioning — and explicitly denies all other principals. This means cross-organization decryption is cryptographically impossible by key policy, not merely prevented by application logic. One organization's compromised IAM session cannot decrypt another organization's credentials.
Bring Your Own Key (BYOK) — Full Key Custody
If your organization requires complete custody of the encryption keys protecting your credentials,
SAML Manager supports Bring Your Own Key (BYOK).
You create a KMS CMK in your own AWS account and grant SAML Manager's provisioning role the minimum
permissions required to use it — kms:GenerateDataKey and kms:Decrypt scoped to the relevant Lambda ARN.
You retain ownership of the key, its rotation schedule, and its key policy at all times.
Revoke the key grant and every credential stored under that key becomes permanently unreadable — even to us.
No support ticket, no internal escalation, no override path exists once the grant is revoked.
AI / LLM Exclusion Policy — Credentials Never Enter AI Systems
SAML Manager does not use generative AI, large language models (LLMs), or autonomous agents anywhere in the credential handling path. Your secrets are:
- Never included in AI model training data
- Never sent to third-party AI services (OpenAI, Anthropic, AWS Bedrock, Azure OpenAI, Google Vertex AI, or any other)
- Never rendered into LLM prompts, agent contexts, or retrieval-augmented generation (RAG) pipelines
- Never accessible to autonomous agents or workflow orchestration systems that interact with AI models
Decryption is performed exclusively by the per-organization provisioning Lambda, whose IAM execution role is scoped to the minimum required permissions and carries no network path to any AI service endpoint. This is enforced at the IAM policy level and KMS key policy level — not just by convention or documentation.