How to connect LiteLLM to your identity provider with SCIM, JWT and SAML
This integration uses SCIM to sync users and teams from your identity provider into LiteLLM, OIDC JWT auth so that each request carries the caller's IdP identity, SAML 2.0 for sign-in to the admin UI, and virtual keys that still have to be issued before anything can call a model. SCIM and JWT auth are Enterprise features. SSO on the admin UI is free for up to 5 users from v1.76.0, and an Enterprise license is needed beyond that. Platform teams usually start with a gateway that runs on shared keys, so the work is to move access from those keys to named identities in stages, keeping the shared keys available until each stage is verified.
The planning error to avoid is assuming the components produce each other's outputs. LiteLLM states that SCIM creating a user does not mint a key, and that JWT auth verifying a token does not create a key by itself. A provisioned user therefore has no model access until a key exists for that user or their team, and a valid token only proves who is calling. Budgets, TPM and RPM limits and model restrictions apply only to the keys and teams configured for them. Each component has to be enabled and configured on its own, and the plan should name a separate owner for the user lifecycle, the key issuance process and admin UI sign-in.
Start the design with the identity provider, because the JWT and SAML settings depend on what it issues. For JWT auth, LiteLLM is configured with JWT_PUBLIC_KEY_URL pointing at the IdP's JWKS or OIDC discovery URL, with optional JWT_AUDIENCE and JWT_ISSUER values and claim mappings for user ID, email and team IDs. Confirm that the IdP places team membership in a claim whose values match the team IDs in LiteLLM, and that the audience matches the value your applications send. For the admin UI, LiteLLM acts as a SAML 2.0 service provider and supports SP-initiated and IdP-initiated flows over HTTP-POST. It can be configured in the admin UI or through SAML_* environment variables, so decide which method your change process allows and record that choice.
Test the chain with a non-production identity before any user depends on it. Create a test user in the IdP, confirm that SCIM provisions the user and team without creating a key, then issue a virtual key and send a request using a token from that user. Check the gateway logs to confirm the request is attributed to the expected user and team, and that a token with the wrong audience or issuer is rejected. Then deactivate the test user and confirm that the access path closes as your design expects. Ask the vendor to confirm how deprovisioning affects existing keys in your version, since that answer decides whether key revocation needs its own step.
What you need in place before configuring identity
Most identity failures in this setup trace back to a prerequisite that was never confirmed. The six items below are the foundation for SCIM provisioning, JWT auth and SAML SSO, and each one should be checked before you change any identity setting on the proxy.
Release line and license scope
Confirm that the version you plan to run supports SCIM, JWT and SAML under your license. The GitHub releases page lists v1.105.1, published October 14, 2026, and LiteLLM supports the four most recent stable minor versions. SCIM and JWT auth are Enterprise features, and SSO is free for up to 5 users from v1.76.0, so confirm your license covers every user and feature. Enterprise code sits under its own license in the enterprise/ directory, while the rest of the repository is MIT, so have your license reviewer check which parts you deploy.
PostgreSQL for virtual keys
Virtual keys need a PostgreSQL database, so plan it before you configure identity. SCIM can sync users and teams, and JWT auth can verify a token, but neither creates a virtual key by itself. Keys carry the model access, budgets, TPM and RPM limits and spend tracking that your IdP identities will rely on. PostgreSQL is the primary supported database in LiteLLM's production guide, so confirm its version, backups and access controls with your database team before you start.
Redis for multi-instance proxies
Redis 7.0 or newer becomes required once more than one proxy instance runs. LiteLLM uses it for shared rate limits, router state and cache, so instances behind one load balancer must see the same counters. If you start on a single instance, decide now whether the design will scale out, because adding Redis later changes the topology and the test plan. Ask your team to confirm the exact Redis deployment model and failover behavior they can operate.
LITELLM_MASTER_KEY in a secret manager
LITELLM_MASTER_KEY must start with sk- and belongs in a secret manager that your platform can read at startup. This key administers the proxy, so it sits above the per-user identities that SCIM and JWT auth introduce. Decide who can read it, how it rotates, and which secret store holds it before the first sync runs. Your security team should also confirm how reads of that store are audited.
IdP endpoints and SCIM client support
LiteLLM's JWT auth needs JWT_PUBLIC_KEY_URL pointing at your IdP's JWKS or OIDC discovery endpoint, and the proxy must reach that URL over the network. Verify reachability from the proxy's own network segment, since a laptop test proves little. Keycloak is one example. It is open source under Apache 2.0, supports OpenID Connect and SAML 2.0, and its own database can run on PostgreSQL 14 to 18. Confirm that your IdP can act as a SCIM client pushing to LiteLLM, because support varies by product and version.
TLS certificates for the admin UI
The admin UI handles SAML and SSO sign-in, so it needs a certificate issued by a CA your users and IdP trust. Plan the hostname, certificate chain and renewal process before configuring SAML, because the SP endpoints and redirect URLs depend on that hostname. Keep the certificate lifecycle with the platform team, and confirm whether your IdP requires signed SAML requests, which affects which key pair you manage.
How SCIM, JWT auth and virtual keys fit together
Three identity legs work together in this setup, and none of them issues the virtual key that a caller needs to reach a model. SCIM runs from your identity provider (IdP) into LiteLLM and creates and updates users and teams so the gateway's records follow the directory. JWT auth handles each request: the caller presents an IdP-issued token, LiteLLM verifies it against the key endpoint set in JWT_PUBLIC_KEY_URL, and claim mappings resolve the user ID, email and team IDs. SAML 2.0 is separate from both. It signs administrators into the admin UI, with LiteLLM acting as the service provider through python3-saml. SCIM and JWT auth are Enterprise features, so confirm licensing before you finalize the design.
The most common gap is assuming that provisioning gives people model access. SCIM creating a user does not mint a key, and JWT verification does not create a key by itself. LiteLLM's identity guidance is explicit that each component has to be turned on for the end-to-end flow to work. A user who signs in through the IdP and presents a valid token still needs a virtual key tied to that user or team. That key is where model access, budgets, TPM and RPM limits and model restrictions are set. Before go-live, decide who issues keys (an administrator, a self-service step or an automated job), who approves budget increases and how keys are retired when someone leaves a team.
Treat the claim mapping as a contract between the identity team and the gateway team. The user ID, email and team ID claims must be present in the token, stable over time and named exactly as the mapping expects. If they are not, spend can be attributed to the wrong identity or requests can be refused. Check the JWT_ISSUER and JWT_AUDIENCE values against a token your IdP actually issues, not against example values in documentation. Team membership changes made in the IdP reach LiteLLM through SCIM, but each affected team's keys, budgets and model lists still need review. Test with one test user per relevant group before you widen access.
SAML covers only who can open the admin UI. Configure it from the admin UI or with SAML_* environment variables, and test both flows. SP-initiated login starts at the LiteLLM login page, while IdP-initiated login starts from the application tile in the identity provider, and each delivers the HTTP-POST assertion differently. Keep administrator accounts separate from application users so that an admin login does not imply model access. The identity guide also includes a CLI login step as part of onboarding. Document it as one part of the user path, and confirm with your LiteLLM version what that login authenticates and what it does not before you give it to developers.
Configuration sequence for the identity integration
This sequence wires LiteLLM to your identity provider in dependency order, so each component is confirmed before the next depends on it. The result is a gateway where users and teams sync from the IdP, callers are identified by token, virtual keys enforce model and budget limits, and admins sign in through SAML.
Confirm license and version scope
Before any configuration, confirm in writing which LiteLLM features your license covers. SCIM and JWT authentication are Enterprise features, and SSO is free for up to 5 users from v1.76.0, with an Enterprise license needed beyond that. Confirm the target release against the four most recent stable minor versions LiteLLM supports, and check the GitHub releases page for the current patch. Your owner for this step is the platform lead, with procurement confirming the license terms. The step is done when the license scope, user count and chosen version are recorded in the change ticket.
Provision PostgreSQL and Redis
Provision PostgreSQL first, because LiteLLM virtual keys require it and it is the primary supported database. If more than one proxy instance will run, also provision Redis 7.0 or newer for shared rate limits, router state and cache. Size each proxy worker against the production guide's suggestion of 1 vCPU and 4 GiB memory per worker, and run one Uvicorn worker per pod if you deploy on Kubernetes. The platform team owns this work in your infrastructure. The step closes when the LiteLLM proxy starts, connects to PostgreSQL, and a second instance can read and write the same Redis state.
Register the LiteLLM client in the IdP
In your identity provider, register LiteLLM as a client or application and record three values: the JWKS or OIDC discovery URL, the issuer and the audience. The identity team owns this step, and the platform team reviews the values. Confirm which token claims the IdP can emit, including the user ID, email and any team or group membership, because those names drive the claim mappings in the next step. If you run Keycloak, the same values come from the client settings in its admin console. The step is done when the three values and the claim list are written into the configuration record, and the discovery URL resolves from the proxy network.
Configure JWT auth and claim mappings
Set JWT_PUBLIC_KEY_URL to the JWKS or discovery URL, set JWT_AUDIENCE and JWT_ISSUER to the recorded values, and map the claims for user ID, email and team IDs to the names your IdP emits. Then test with two tokens issued by your IdP: a valid token for a test user, which must be accepted, and a bad token, such as one with the wrong audience or an expired timestamp, which must be rejected. Keep a copy of each test result. JWT verification does not create a virtual key by itself, so no key appears at this point. The step is done when the accepted and rejected results match the expected outcomes and the team claim resolves to the correct team identifier.
Enable SCIM and verify sync
Enable SCIM so users and teams sync from the IdP into LiteLLM, and create a test user and a test team in the IdP. Confirm the test user appears in LiteLLM with the correct team memberships, and that moving the user between groups updates those memberships. Then deactivate or remove the test user in the IdP and confirm that access is removed in LiteLLM. Remember that SCIM creating a user does not mint a key, so each team still needs keys issued in a later step. The identity team and platform team run these checks together. The step is done when creation, membership change and deprovisioning each produce the expected result, with evidence saved for the review.
Issue team virtual keys with model and budget scope
Issue virtual keys for each team, scoped to the models that team is approved to call and to the budgets it has been allocated. Virtual keys support per-key, per-user and per-team budgets, TPM and RPM limits, temporary budget increases and model restrictions, so set the values your governance owners approved. Confirm the allocation numbers with the budget owner rather than taking defaults. Test one key against an approved model, which should succeed, and against a model outside its scope, which should be refused. The step is done when the scope checks pass for each team and the key records show the assigned budget and limits.
Configure SAML for the admin UI
Configure SAML 2.0 for admin UI sign-in, either through the admin UI or with SAML_* environment variables, using the service provider settings and IdP metadata from your identity provider. Test an SP-initiated login, started from the LiteLLM admin UI, and an IdP-initiated login, started from the IdP portal, since both flows use HTTP-POST and both must work for your admins. Confirm that a user without admin rights is not granted admin access. Note that the admin UI SSO options are separate from the JWT path used for API callers. The step is done when both login flows succeed for an admin and the non-admin test user is restricted, with the metadata version and certificate expiry noted.
Move secrets and run go-live review
Move LITELLM_MASTER_KEY, which must start with sk-, and the SAML signing and encryption secrets out of plain configuration and into your approved secret manager. Confirm the proxy reads them from that store at startup and that they are absent from container images, manifests and shell history. Then run a go-live review with the platform, identity, security and compliance owners. The review should cover the test results from each earlier step, who holds the master key, how keys are rotated, and the owner for IdP group changes. Ask your partner or internal team to confirm the upgrade path for the chosen release before go-live. The step is done when every check is signed off and the review record is filed.
Which IdP attributes map to which LiteLLM objects
This table maps each identity attribute or provisioning record from the identity provider to the LiteLLM object it populates. Read each row from left to right to see where an identity value lands, what it controls, and what to check in your own environment before go-live. Claim and attribute names vary by identity provider, so confirm every name in your tenant before you map anything.
| IdP source | LiteLLM object | Purpose | What to confirm |
|---|---|---|---|
| JWT user identifier claim, such as sub | LiteLLM user ID through JWT claim mapping | Ties each request to one stable user identity for attribution and spend | Exact claim name, and that its value stays stable across tokens |
| JWT email claim | LiteLLM user email | Links the caller to records in logs, budgets and admin reports | Claim name, whether the email is verified, and whether it can change |
| JWT group or team membership claim | LiteLLM team IDs | Scopes model access, budgets and logging to the caller's teams | Claim name, group format, and whether values are IDs or display names |
| SCIM user resource | LiteLLM users | Creates, updates and deactivates users from the IdP | Which attributes sync, and how quickly deprovisioning disables access |
| SCIM group resource | LiteLLM teams | Keeps team membership aligned with IdP groups | Group-to-team matching rules and how membership changes propagate |
| SAML assertion attributes for role or group | Admin UI roles and access | Controls who can sign in to the admin UI and with which privileges | Attribute names, the values the IdP sends, and the role each value maps to |
| Admin-issued in LiteLLM, not sent by the IdP | Virtual key bound to a user or team | Sets allowed models, budget, and TPM or RPM limits for each key | Limits chosen by the admin, since no identity claim sets them |
How to verify each leg before go-live
Verify each leg of the identity chain separately before you call the LiteLLM gateway ready for production. The SCIM sync, the JWT check on API calls, the virtual key layer and the SAML login for the admin UI fail in different ways, and a single end-to-end login that works tells you very little about the others. Build a short test matrix with one or more cases per leg, run it against a staging proxy that uses the same PostgreSQL database layout, Redis setup and IdP tenant settings as production, and assign an owner to each row before the first run.
For JWT auth, test that a token issued by your IdP for a real test user is accepted and that the request is attributed to the expected LiteLLM user and team through the claim mappings you configured for user ID, email and team IDs. Then send tokens that should fail: an expired token, a token whose audience does not match JWT_AUDIENCE, and a token from a different issuer than JWT_ISSUER. Each rejected token should produce a denial, not a fallback to a default identity. If you did not set JWT_AUDIENCE or JWT_ISSUER, record that as a gap and decide whether the risk is acceptable, because the checks you skipped are the ones an assessor will ask about.
For SCIM, run a create, an update and a deactivate event from the IdP against the test tenant and confirm the resulting state in LiteLLM for both users and teams. Creating a user through SCIM does not mint a virtual key, so the test should also confirm that no key appears by accident and that a key only exists when someone issues one. For deactivation, check that the user can no longer authenticate through JWT or SSO and that existing keys tied to that identity are handled according to your offboarding procedure. Confirm the exact behavior with your IdP connector and the LiteLLM version you run, since sync semantics for group changes can differ.
For virtual keys, test three things: a key requested for a team it does not belong to is refused, a key requested for a model outside its permitted list is refused, and a budget or rate limit is enforced. For the budget case, drive spend up to a low test limit, confirm the next request is blocked, and then test a temporary budget increase to confirm it is applied and expires as intended. For the SAML leg, test SP-initiated login and IdP-initiated login separately, since both flows reach the admin UI through different paths, and test a user who has been revoked in the IdP to confirm the login fails cleanly without exposing an error page that reveals configuration details.
Record the results in a format your change review can read: test ID, leg, input, expected result, actual result, tester, date and the LiteLLM and IdP versions under test. Store the evidence with the change ticket. Compliance evidence is prepared by your organization, and DeployOpen can help structure it, but independent auditors decide whether your controls conform to a given framework. Plan to rerun the full matrix after any LiteLLM upgrade, IdP configuration change or claim mapping change, not just the affected leg.
Hardening the identity path
The identity path is only as strong as the controls around it. These six cards cover the secrets, admin access, token trust, key scope, IdP patching and deprovisioning that a LiteLLM identity design depends on. Work through them in the order your environment is built, and confirm every Enterprise-only item against your license before relying on it.
Protect the master key and SAML material
LITELLM_MASTER_KEY is the root credential for the proxy, and it must start with sk-. Store it in a secret manager that the workload reads at runtime, and keep it out of manifests, Helm values and image layers. Apply the same handling to the SAML service provider's signing and any encryption keys. Confirm who can read these secrets, whether rotation is documented, and whether either value can reach logs or support bundles during troubleshooting.
Limit admin access and confirm audit controls
Restrict the admin UI to administrators who authenticate through SAML, so a local login path cannot bypass the IdP. Review which local accounts remain and how break-glass access is recorded. IP allowlisting and audit logs are listed as Enterprise features in LiteLLM's documentation, so confirm both are included in your license before designing around them. If they are, apply the allowlist to admin ingress and forward audit events to your existing log platform. If they are not, enforce equivalent network limits at the load balancer or ingress.
Keep JWT key discovery verifiable
Point JWT_PUBLIC_KEY_URL at the IdP's JWKS or OIDC discovery endpoint over HTTPS, and confirm the proxy can reach and validate that endpoint. Set JWT_ISSUER and JWT_AUDIENCE so tokens minted for other applications are refused. Check that the certificate chain is trusted inside the cluster, that egress rules allow the endpoint, and that the team has a documented plan for key rotation at the IdP, including how the proxy refreshes its cached keys.
Scope virtual keys by model and budget
Virtual keys still have to be issued after SCIM and JWT auth are working, and each key should carry only the models its owner needs. Set per-key, per-user or per-team budgets, and add TPM and RPM limits where teams share capacity. Record approvals for temporary budget increases. Confirm which SCIM-synced teams map to which keys, because a user created by SCIM does not receive a key automatically.
Patch the IdP on a supported release
If Keycloak runs the identity path on Kubernetes, install the operator through Operator Lifecycle Manager and set manual approval for operator updates, as the Keycloak Operator documentation strongly recommends. Keycloak's current release is 26.8.1, and each minor release can change behavior, so review its release notes and test upgrades in staging before approving them. Decide whether database schema migration runs automatically at startup or is applied manually, and confirm your chosen release line is supported for your environment.
Review SCIM deprovisioning as the leaver control
Treat SCIM as the joiner, mover and leaver control for LiteLLM users and teams. When the IdP deactivates a user or removes them from a group, confirm that the sync disables the user, updates team membership and blocks their existing virtual keys. Test each path with a disposable account. For joiners, confirm that a SCIM-created user still needs a key issued before access works. Confirm who owns the SCIM token and how often the sync runs.
Common failures in LiteLLM identity integrations
This table lists common failures when LiteLLM is wired to an identity provider through JWT auth, SCIM and SAML SSO, with the likely cause and fix for each. Read it by matching the symptom you see to the cause, then checking the fix against your IdP settings and proxy configuration. The main takeaway is that identity sync alone does not grant model access, so virtual keys, shared Redis and PostgreSQL must be in place too.
| Symptom | Likely cause | Fix |
|---|---|---|
| Valid IdP token returns unauthorized | Audience, issuer or JWKS URL does not match the token, or clock skew between hosts | Compare the token's aud and iss with JWT_AUDIENCE and JWT_ISSUER, confirm JWT_PUBLIC_KEY_URL, and sync host time |
| User logs in but has no model access | No virtual key issued, since JWT auth and SCIM do not mint keys | Issue a virtual key per user or team with allowed models and budgets |
| SCIM users appear but teams do not | Group claims not mapped to team IDs, or the IdP does not push group membership | Map group claims to team IDs and confirm the IdP pushes group membership to LiteLLM |
| Removed employee keeps access | Virtual keys stay active after the IdP deprovisions the user | Revoke or block the user's virtual keys as part of offboarding, then test it |
| SAML login loops or fails signature checks | Certificate mismatch, wrong ACS URL or clock drift | Match the IdP signing certificate and ACS URL exactly, then correct clock drift |
| Admin UI SSO works for five users but not beyond | The free SSO limit from v1.76.0 is five users; more users need an Enterprise license | Confirm the license tier with LiteLLM before rolling SSO out to more than five users |
| Proxy instances disagree on rate limits | No shared Redis, or Redis older than 7.0 once more than one proxy instance runs | Run Redis 7.0 or newer, shared by all proxy instances |
| Virtual keys fail to save | PostgreSQL is not configured as the database | Configure PostgreSQL before issuing keys, since virtual keys require it |
Questions buyers ask before hiring outside help
What drives the cost of a LiteLLM SCIM, JWT and SAML integration?
Scope, licensing and testing depth drive the cost more than any single component. Enterprise licensing is the first line item: SCIM and JWT auth are Enterprise features, and admin UI SSO is free for up to 5 users from v1.76.0, with an Enterprise license needed beyond that. Other drivers are the number of identity providers and teams, how IdP groups map to LiteLLM teams in the SCIM group model, the number of SAML settings and attributes to map, how much negative testing is required, and secret manager work if provider keys and virtual keys move into Vault, AWS, Azure, Google or CyberArk. The license is a recurring cost and the integration build is one-time. Ask for a fixed-scope quote with each driver listed as a separate line.
How long does a LiteLLM identity integration take to deliver?
Duration depends mostly on how ready your identity provider is and how quickly approvals come through. DeployOpen agrees a fixed scope and timeline in writing before work starts, so the schedule is tied to named deliverables. The main dependencies are IdP admin access, a test tenant, certificates for SAML, network paths from the gateway to the JWKS or discovery URL and the SCIM endpoint, change windows for production, and the time security reviewers need to approve claim mappings and group rules. Ask for the timeline with each dependency listed, and identify which dependencies sit outside the project team so you can track them.
What do we need to provide before an identity integration starts?
Plan to provide the following before the build starts:
- IdP admin access to configure SCIM, OIDC clients and SAML applications
- Test accounts across each group you plan to map
- Network paths from the LiteLLM proxy to the IdP's JWKS or discovery URL and SCIM endpoint
- Certificates and signing metadata that SAML requires
- Secret manager access for the store where keys will be kept
- A named owner who approves claim mappings and team rules
You also need a PostgreSQL database, which virtual keys require, and Redis if more than one proxy instance runs. A staging environment that matches production makes testing far more reliable. Without a named owner, claim mapping decisions tend to stall during testing.
Can our internal team wire LiteLLM to our identity provider themselves?
Yes, an internal team can do this if it has the LiteLLM documentation, written test cases and an Enterprise license for SCIM and JWT auth. The provisioning guide explains how the pieces fit, and the JWT auth, SAML SSO and virtual key docs cover the settings. What teams most often underestimate is the sequence: SCIM creates users, JWT verifies tokens, and virtual keys still have to be issued, so each component must be turned on and tested together. Teams that already operate an identity provider and an API gateway usually have the skills. Teams new to SAML or claim mapping should allow extra time for testing with live group membership. Confirm your Enterprise scope with the vendor before planning.
Does LiteLLM SCIM provisioning or JWT auth require an Enterprise license?
Yes. SCIM provisioning and JWT authentication are both Enterprise features in LiteLLM. Admin UI SSO with Google, Microsoft Entra ID, Okta or a generic OIDC provider is free for up to 5 users from v1.76.0, and an Enterprise license is needed beyond that, according to the LiteLLM docs. Confirm with the vendor whether your user count and your SAML flow fall inside the free tier before you plan the work. Enterprise also includes audit logs, team RBAC, IP allowlisting and secret manager integrations, which regulated organizations often need. Ask the vendor to confirm license terms in writing, because the scope of the free tier can change between releases.
What recurring work follows a LiteLLM identity integration after go-live?
Recurring work starts at go-live and continues for as long as the gateway runs. Plan for:
- License renewals for Enterprise
- Key rotation for LITELLM_MASTER_KEY, identity provider client secrets and SAML certificates
- LiteLLM upgrades on a supported minor line, since the four most recent stable minor versions are maintained
- Identity provider upgrades, such as Keycloak, which plans four minor releases a year
- Access reviews of synced users, teams and virtual keys
Each LiteLLM upgrade may need a database migration and retesting of claim mappings and SAML settings. Ask for a support model that lists these tasks, says who performs them and states the response targets in the contract.
What should we ask for in a quote for this integration?
Ask for a written, fixed-scope quote that lists each cost driver as its own line. Include the identity providers in scope and their versions, the number of teams and the group-to-team model, and whether SCIM, JWT auth and SAML are each covered. The quote should state the Enterprise licensing assumptions and who buys the license. It should describe test depth, including negative tests such as expired tokens and removed users, plus any secret manager work and which provider it covers. Check that the client responsibilities from the prerequisites appear in the quote, along with the acceptance criteria and the post-go-live support model. Ask which deliverables are one-time and which recur. A quote without these lines is hard to compare against an internal build.
Why does SCIM sync users but still not issue LiteLLM keys?
SCIM creates or updates users and teams in LiteLLM, but it does not mint a virtual key. JWT auth verifies a token from the IdP and identifies the caller, and verifying a token does not create a key either. A key is still needed to authorize model access, budgets and spend tracking. The end-to-end flow therefore needs all three pieces: SCIM for identity records, JWT for caller verification, and virtual keys issued to the right users or teams with model and budget limits. Test the full path: a removed user should lose access, an expired token should be rejected, and a key should work only for its permitted models. Check the claim mapping for user ID, email and team IDs against live tokens before go-live.
How DeployOpen scopes and delivers this integration
DeployOpen wires LiteLLM to your identity provider as one scoped piece of work: SCIM sync, OIDC JWT auth, SAML SSO for the admin UI and the virtual keys that still have to be issued. Each component is planned, built, tested and handed over in your own infrastructure, with the Enterprise license requirements confirmed before work starts.
How we scope
- Engagements are fixed-scope, with the components, deliverables and timeline agreed in writing before work starts.
- We confirm which LiteLLM features your license covers, since SCIM and JWT auth are Enterprise features.
- We map which IdP groups become LiteLLM teams and which claims carry user ID, email and team IDs.
How we build
- We configure SCIM so users and teams sync from your IdP, then test deprovisioning of a removed user.
- We set JWT_PUBLIC_KEY_URL, audience and issuer, then verify that claim mappings resolve to the right LiteLLM identity.
- We enable SAML 2.0 for the admin UI with SP-initiated and IdP-initiated flows, tested against your IdP metadata.
How we hand over
- We issue and document the virtual key process, since SCIM and JWT verification do not create keys on their own.
- We deliver a written runbook covering claim mappings, group-to-team rules, certificate rotation and recovery steps.
- We walk your identity and platform teams through test results and the configuration they will maintain.
How we support
- Ongoing support, upgrades and continuous testing are available as a retainer after handover.
- We can plan upgrades on a supported LiteLLM release line and review identity configuration after each change.
- Support scope, response expectations and access are agreed in the written scope before work starts.
