How Zitadel works as a SAML identity provider for applications
Zitadel implements SAML 2.0 alongside OpenID Connect and OAuth 2.0, and each application that only accepts SAML logins is connected to it as a SAML service provider. This matters most when a SaaS product or internal application cannot be changed to use OIDC and must authenticate against Zitadel as it is. DeployOpen plans, configures and verifies these connections in infrastructure the client controls, so the identity provider, its database and its signing material stay under the client's governance. The per-application details, including the entity ID, the assertion consumer endpoint, the NameID format and the required attributes, must be confirmed against each application's own SAML settings before any configuration is written, because vendors name and document these differently.
A SAML login follows a fixed exchange. The application, acting as the service provider, sends an authentication request to Zitadel. Zitadel checks whether the user already has a session and, if not, presents its login pages, which can hand off to an upstream identity provider configured for the user's organization. Once the user is authenticated, Zitadel builds a SAML response containing a signed assertion and sends it through the user's browser to the service provider's assertion consumer endpoint. The application validates the signature against the certificate it holds from Zitadel's metadata, reads the attributes and creates its own local session. Each step is a place where a mismatch between the two sides produces an error that looks like a generic login failure, so the team should trace one complete login with a test user before cutover.
Most of the setup work sits in Zitadel's object model. Users live in an organization inside an instance, and each application is registered inside a project, which groups applications, roles and grants. Decide early which organization and project will own each SAML application, because roles and grants follow the project, and moving ownership later means recreating access rules. For applications used by several customer organizations, decide whether the SAML entry is shared or duplicated per tenant, and check that the application's own tenant model can accept the entity ID and metadata you provide. Treat metadata exchange as a controlled change: record the entity IDs, the signing certificate and its expiry date, and the people who must receive an update when the certificate rotates.
Signed assertions and attribute mapping are where most integrations need attention. Confirm whether the application requires the assertion, the response or both to be signed, which signature algorithm it accepts, and whether it expects a specific NameID format such as an email address or a persistent identifier. Map each attribute the application needs, such as email, display name or a role claim, to a value Zitadel can supply, and record the attribute names exactly as the application spells them, since a single character difference will fail silently in many products. Test with at least three accounts: one with the full set of roles, one with a reduced set, and one that should be refused access.
The limitation to check against each application is whether it supports only service-provider-initiated login, where the flow starts at the application's own login page. If the application can only be reached from a portal or launch tile, the flow starts at the identity provider instead, and the application must accept an unsolicited response. Confirm with the vendor how the application handles this case, and confirm how Zitadel's current documentation treats unsolicited responses for SAML applications before you commit to a user journey. Then plan the launch path, bookmarks and support guidance for users who arrive at the application from the wrong starting point.
What you need before connecting a SAML application to Zitadel
A SAML connection depends on prerequisites on both sides of the trust relationship. Most delays come from items nobody assigned: a database version outside the supported range, a hostname the application cannot reach, or a service provider team that has not supplied its entity ID. Confirm each item below before you create the first SAML application in Zitadel.
Self-hosted Zitadel instance
Run a self-hosted Zitadel instance on a current supported release, which you can identify on the Zitadel releases page on GitHub. Read the release notes for the version you choose, because console screens and SAML-related behavior may change between releases. Record the exact version in your runbook so your team and the service provider team work from the same build. Confirm that the instance is reachable at a public HTTPS hostname with a valid certificate, since that hostname becomes part of the issuer and metadata the application trusts.
PostgreSQL 14 through 18
Zitadel uses PostgreSQL as its database, and the documented self-hosting support covers PostgreSQL versions 14 through 18. Choose a major version inside that range and confirm that your platform team can back it up and restore it before go-live. Decide who owns connection settings, TLS to the database and future major version upgrades. A database fault during a SAML sign-in usually looks like an identity failure to users, so the same team should be on call for both.
Organization and project structure
Zitadel places users and projects inside an organization, which sits within an instance. Decide which organization will own the application, then create a project to group the application, its roles and its grants. Settle this before creating the SAML application, because changing the owning organization later may require a new metadata exchange. Check that the users who need access belong to that organization, or that it is linked to the identity source you plan to use.
SAML admin access to the application
Someone on your side needs administrator access to the application's SAML configuration screens to upload Zitadel's metadata, set the entity ID and ACS URL, and map attributes. Confirm that this person can change those settings in a non-production tenant first. Some applications accept a metadata URL, others require a file upload or manual entry, so check the options before planning the exchange. Ask the vendor whether the application supports only service-provider-initiated login, because that limits how users can start sign-in.
Service provider values
The service provider team supplies the values Zitadel needs to trust the application: the entity ID, the assertion consumer service (ACS) URL and the SP metadata. Agree in writing who owns each value, which environment it applies to and how changes are requested. Ask the team to confirm the binding and signing expectations their application requires. A mismatch here often appears as a failed login without a clear error message, so verify these values before users are involved.
AGPL 3.0 license review
Since Zitadel v3.0, released on 31 March 2025, the core, Console and hosted login are licensed under the GNU Affero General Public License 3.0. APIs, SDKs, proto definitions, documentation, Helm charts and Terraform configurations remain under Apache 2.0. Ask your legal team to confirm what the AGPL obligations mean if you modify Zitadel or make it available to users over a network, and which parts of your integration code fall under Apache 2.0.
How SAML metadata, assertions and sessions flow between Zitadel and the application
A SAML integration works only when both sides hold the same facts about each other. In this setup Zitadel is the identity provider (IdP): it authenticates the user and issues signed statements about that user. The application is the service provider (SP): it trusts those statements and then creates its own session for the user. Most design decisions in this section follow from that split. Zitadel decides whether the user may sign in and what the assertion says. The application decides whether to accept the assertion and which local account it maps to. The two sides exchange metadata before any login can succeed. Zitadel publishes its entity ID, its single sign-on endpoint and its signing certificate. The application publishes its own entity ID, its assertion consumer service (ACS) URL, and the signing certificate it uses if it signs requests. Each side registers the other's values. Confirm which party generates the metadata file, how the entity IDs are named across environments, and who owns certificate renewal. An entity ID or ACS URL that differs by one character from what the other side expects is a common cause of failed logins, so compare these values exactly during testing.
When a user signs in, the application sends an authentication request to Zitadel's single sign-on endpoint, usually through the browser. Zitadel shows its login pages, including any upstream federation the user's organization uses, and then sends an assertion back to the ACS URL. The assertion is signed with Zitadel's key and carries the subject identifier (NameID), the issuer, an audience restriction naming the application, validity time conditions and any attributes Zitadel is configured to include. The application must verify the signature against the certificate it received in metadata, check the audience and time window, and then map the NameID and attributes to a local user. Attribute mapping is a design decision, not a default setting. Decide which attributes the application needs, such as email, display name or group membership, and confirm that Zitadel can supply each one from the user's record. Agree with the application owner which attribute will serve as the stable account key. An identifier that changes when an email address changes will create duplicate accounts in the application.
The application's session and Zitadel's session are separate. After a successful assertion, the application creates its own session, and it usually continues to honor that session until it expires, even if the user's Zitadel session has ended. Single logout depends on both sides supporting the same logout bindings and on the application sending or accepting logout messages. Test what happens when a user signs out of the application, signs out of Zitadel, or has their account disabled, and record the expected behavior for each case with the application team. Access also depends on where objects sit in Zitadel's hierarchy. Users live inside an organization, and applications are grouped inside a project with roles and grants. The organization a user belongs to, and whether the project grants that organization access, determine who can sign in to a given SAML application. Map each application to a project and each user population to an organization before building anything. Illustrative example: a partner company whose users sit in a separate organization will need a grant before its users can reach an application that lives in your main project.
Two behaviors must be confirmed before the design is fixed. First, check the Zitadel SAML documentation for the supported initiation flows, and confirm whether IdP-initiated login (where the user starts at Zitadel and is sent to the application) is available in your Zitadel version. Do not assume it is available because SP-initiated login is. Second, the SP-initiated only limitation has to be checked application by application. Some applications accept only logins that begin at the application, while others need a portal or a link from the identity provider. Ask each application vendor or internal team which flows they require, and record the answer in the integration plan. Before the build starts, write down the entity IDs, ACS URLs, certificate owners, attribute map, organization and project placement, and the initiation flow for each application. Then test a sign-in, a sign-out and a disabled-user attempt in a non-production instance. These records will also support later upgrades and certificate rotations.
Setup sequence for connecting a SAML application to Zitadel
This sequence connects one SAML service provider to Zitadel in a test environment before any production cutover. Each step closes with a check you can run yourself, so a fault is found where it was introduced. The result is a working SP-initiated login for a granted test user, with the assertion's audience, signature and attributes confirmed.
Create or select the organization and project
Work in the Zitadel organization that holds the users who will sign in to the application, and create a project to contain the application and its roles. An identity administrator usually performs this step, and the application team should receive console access to the same organization. Check that the project appears under the organization and that the test users you plan to use are visible in it. Confirm the exact console labels against the Zitadel version you deploy, because menus change between releases.
Register the application as a SAML application
Inside the project, add a new application and select the SAML option. Use a name the support team will recognize, since it appears on grant and user screens during troubleshooting. Before you build further, confirm that the SP-initiated flow the application needs is supported in your version, because some applications depend on flows you must verify individually. Check that the application appears in the project's application list with SAML as its protocol type.
Obtain the Zitadel IdP metadata and signing certificate
Download the identity provider metadata from the application's SAML configuration in Zitadel, along with the signing certificate it references. The application team needs the entity ID, the single sign-on endpoint and the certificate's validity dates, so record them in your change record. Check the metadata file by opening it and confirming that the entity ID matches the value shown in the console and that the certificate is current. Schedule a renewal reminder for the certificate before go-live.
Import or enter the application's SP metadata
Give Zitadel the service provider's entity ID and assertion consumer service URL, either by uploading the SP metadata file or by entering the values manually. Ask the application owner which method the application supports, since some publish metadata at a fixed URL and others only accept manual entry. Compare the saved values with the application's own SAML configuration screen, checking that the entity ID and ACS URL match character for character, including trailing slashes. A mismatch here often causes the first login to fail.
Set the NameID format and attribute statements
Choose the NameID format the application expects, such as email or a persistent identifier, and map the user attributes it needs, such as email address, given name and surname, to the attribute names it reads. Many applications treat attribute names as case-sensitive, so copy them exactly from the application's documentation. Check the configuration by capturing one test assertion after step seven and confirming that the NameID value and each attribute name and value match the application's specification.
Assign roles and grants to the test users
Create a role for the application inside the project, then grant that role to one test user who should have access. Grants decide which users can sign in to the application through this project, so the checks in the following steps depend on this assignment. The grant should be made by a person with project administration rights and recorded in your change log. Check that the grant appears on the test user's record with the expected role before you start the login test.
Run a test login and decode the assertion
Start an SP-initiated login from the application as the granted test user, then capture the SAML response in your browser or with a SAML tracing tool. Decode it and check that the audience restriction equals the SP entity ID, that the destination matches the ACS URL, and that the response and assertion signatures verify against the certificate from the metadata step. Also confirm that the validity window has not expired. If the login fails, the decoded response shows whether the fault lies in signing, audience or attributes.
Confirm refusal for a user without a grant
Sign in as a second test user who exists in the same organization but has no grant for this application. Check that Zitadel refuses the login and that the application does not create a session for that user. Record the error message shown so the support team can recognize it later. Repeat this check whenever roles or grants change, because removing a grant should stop access, and the refusal is the evidence that the grant model works before go-live.
Mapping Zitadel user fields and roles to SAML attributes
This table maps each Zitadel user field and role source to the SAML NameID or attribute the application expects and the application field it feeds. Attribute names and NameID formats are set by each application, so copy them from that application's documentation before you configure the mapping. Role and group claims depend on how your team models project roles and user grants, so verify them with test users in each role.
| Zitadel user data | SAML NameID or attribute | Application field it feeds | Check to confirm it |
|---|---|---|---|
| Login name | NameID value, with the format the application requires (confirm in app docs) | Username or account identifier used to match the user | Sign in as a test user and confirm the app links the session to the expected existing account |
| Verified email | Email attribute, named by the application (confirm in app docs) | Email address for notifications and account matching | Decode the assertion and confirm the value is the verified address, not an unverified one |
| Given name | First name attribute, named by the application (confirm in app docs) | First name on the application profile | Compare the attribute value in the assertion with the given name on the Zitadel user profile |
| Family name | Last name attribute, named by the application (confirm in app docs) | Last name on the application profile | Compare the attribute value in the assertion with the family name on the Zitadel user profile |
| Organization membership | Organization attribute only if the application scopes accounts by tenant | Tenant or account scoping in a multi-tenant service provider | Confirm the application needs this claim and that the value matches the Zitadel organization of the test user |
| Project role keys from user grants | Multi-valued role or group attribute, named and shaped by the application | App roles, groups or permission mapping | Confirm role key spelling matches the application configuration exactly and the claim lists only the roles granted to that user |
| Role claim behavior across projects | Role attribute populated from grants in the project tied to the application | Access decisions inside the application | Test one user per role and one user with no grant, and confirm access matches the expected outcome in each case |
Security settings to confirm for SAML signed assertions
The protection a SAML sign-in gets depends on both Zitadel's settings and the application's own validation settings, such as whether it requires signed responses or signed assertions. Each card below is a setting to confirm for every application you connect, because a setting that is correct in Zitadel can still go unenforced by a service provider that does not check it.
Signed responses and assertions
Decide whether Zitadel signs the SAML response, the assertion, or both, and confirm the application's metadata and configuration match that choice. Signing protects the message from tampering in transit, but only if the application verifies the signature. Many applications accept either form, so confirm which elements the application requires. Test by sending a deliberately altered assertion in a non-production environment and confirm that it is rejected.
Signing certificate lifecycle
Name an owner for the signing certificate and record where its private key is held. Track its expiry date with an alert well before it lapses, because an expired certificate breaks sign-in for every application that trusts it. When rotating, publish the new certificate in the metadata and confirm each application refreshes its copy before the old one is retired. Confirm whether each application refreshes by metadata URL or by manual upload.
Audience and recipient restrictions
Confirm that each assertion names the application's entity ID as its audience and targets the application's assertion consumer service endpoint as the recipient. An application that does not check these values can accept an assertion issued for a different service provider. Ask each application's team which of these checks it performs, and test by sending an assertion with a wrong audience in a non-production environment.
Short validity and clock tolerance
Keep the validity window of an assertion short, and limit the allowed clock skew between Zitadel, the application and any intermediary to what the environment requires. Long windows widen the period in which a captured assertion can be replayed. Confirm whether the application enforces the not-before and not-on-or-after conditions and whether it records assertion IDs to block replay. Check time synchronization on every host involved in the flow.
TLS on all endpoints
Serve the Zitadel login pages, the SAML endpoints and the metadata URL over TLS only, and confirm the application's assertion consumer endpoint and metadata are also served over HTTPS. Signatures do not protect the browser redirect path if the transport is exposed. Check certificate chains, disable plaintext listeners on ingress or load balancers, and confirm that the application validates the certificate of any metadata URL it fetches.
Organization and role access
Decide which Zitadel organizations and roles can reach each application, using project grants so that only users granted the application can receive an assertion for it. Check that users from one customer organization cannot sign in through a grant meant for another. Confirm that the application maps roles from the assertion and denies access when the expected attribute is missing.
Common SAML failures when connecting Zitadel to an application
This table lists the SAML failures most often seen when a service provider is connected to Zitadel, with the likely cause, the fix and the check that confirms the cause. Work through the rows in order, since signature, audience and ACS URL errors usually block sign-in before attributes or account matching are reached. Confirm each cause with the check in the last column before changing configuration.
| Failure | Likely cause | Fix | Check that confirms the cause |
|---|---|---|---|
| Invalid signature | Application holds a stale or mismatched signing certificate, often after a certificate change or a manually copied metadata file | Re-import the current signing certificate or metadata from Zitadel into the application | Compare the certificate fingerprint stored in the application with the certificate in the metadata Zitadel provides |
| Audience or entity ID mismatch | The Audience value in the assertion differs from the entity ID the application expects | Align the entity ID configured in the application with the audience Zitadel issues, then re-register if needed | Decode a test assertion in a SAML tracer and compare its Audience element with the application's configured entity ID |
| ACS URL mismatch | The assertion consumer service URL in the request differs from the endpoint registered in Zitadel in scheme, host, path or trailing slash | Register the exact ACS URL the application sends, character for character | Compare the AssertionConsumerServiceURL in the AuthnRequest with the ACS URL stored in the Zitadel application settings |
| Assertion expired or not yet valid | Clock drift on the application or Zitadel host moves the current time outside the NotBefore or NotOnOrAfter window | Synchronize both hosts with NTP and confirm the clock tolerance the application allows | Compare the timestamps in the assertion with UTC time on the application host and check NTP synchronization status |
| Account not found in the application | The NameID format or value Zitadel sends does not match the field the application uses to find users | Agree the NameID format and value (for example, email address) and map the application's lookup field to it | Inspect the NameID element and its Format attribute in a test assertion against the application's user matching field |
| Empty or incomplete user profile | Required attributes are missing from the attribute mapping, or their names or formats differ from what the application expects | Map each attribute the application requires, using the name and format it documents | Compare the AttributeStatement in a test assertion with the attribute list in the application's SAML requirements |
| Login initiated from the identity provider fails | The application accepts only service-provider-initiated sign-in, so unsolicited assertions from Zitadel are rejected | Start sign-in from the application, or confirm that the application and Zitadel version support identity-provider-initiated flows before enabling them | Review the application's SAML documentation and run a login started from Zitadel to see how the application responds |
Testing each SAML connection before users depend on it
Treat each SAML connection as a release gate. No application should go live for users until its test plan has passed in the environment that will serve them. For every application, create a dedicated test organization inside the Zitadel instance, since organizations are where projects, users and grants live. Give that organization its own test users, one for each role the application expects, plus a user with no grants at all. Keep these identities separate from production people so a failed test never touches a real account and the results stay clean enough to keep as evidence.
The positive tests sign in through the service provider, which is the only starting point Zitadel supports for this connection, and check that each test user reaches the application with the role and access the grant should give. Run the same checks for every role, not just the administrator. The negative tests matter as much. Confirm that a test user with no grant on the project is refused, and that a user from a different organization is refused even when the role name matches. Record exactly what the application displays in each case, because a refusal that looks like a generic error can hide a misconfigured grant or a broken mapping.
Capture a SAML response from a test login and decode it before trusting the connection. Check that the issuer matches the entity ID you exchanged in the metadata, that the audience restriction names the application's entity ID, and that the NameID format and each mapped attribute appear with the values you expect. Confirm the signature is present and validates against the signing certificate in the published metadata, and agree with the application owner which part of the message must be signed. Check the timestamps against the tolerance the application allows for clock skew. Confirm these expectations against the Zitadel version you run, since behavior can differ between releases.
Rehearse a signing certificate rotation in staging before you need one in production. Generate the replacement, publish updated metadata, and confirm with the application's documentation whether it accepts both certificates during an overlap window. Verify that logins succeed during the overlap and after the old certificate is removed. Then test the sign-out path. Check what happens when a user signs out of the application, whether the application ends its own session, and what a user sees after signing in again. Finally, sign in, leave the session idle until the application's timeout and Zitadel's session lifetime have passed, and confirm the user is asked to authenticate again. Confirm the configured lifetimes with the Zitadel and application documentation rather than assuming defaults.
The depth of testing depends on two things you should decide early. If many applications share one Zitadel instance, a change to shared settings affects all of them, so the regression set grows and each application's organization needs its own test identities. If you run separate staging and production instances, run the full plan in staging, then repeat a smaller set of positive and sign-out checks in production after cutover. Keep a record for every run: a test identifier, date, tester, Zitadel and application versions, expected and observed results, and redacted decoded assertions. Store these with the change record so the client holds the evidence. DeployOpen can prepare the plan and the records, but auditors and internal reviewers decide whether they are sufficient.
Questions teams ask before connecting SAML applications to Zitadel
How much does it cost to connect SAML applications to Zitadel?
Cost depends on the written scope, which DeployOpen agrees in writing before work starts, so no single figure applies to every team. Fees cover planning, configuring Zitadel, metadata exchange, attribute mapping, testing and handover documentation for each application. Some costs recur, including your own infrastructure, any Zitadel subscription you choose, and any support retainer. The main cost drivers are the number and type of applications, the depth of attribute and role mapping, and how well each service provider documents its SAML behavior. Ask for a quote that lists each application, its mapping needs, and whether testing and certificate rotation are included. For Zitadel plan structure, check the Zitadel pricing page, where the Enterprise plan offers custom support agreements and technical account management.
How long does it take to connect a SAML application to Zitadel?
Duration is set in the written scope and follows the same inputs that drive cost: application count, mapping complexity, documentation quality and the number of organizations. A single well-documented application with simple attributes is a short piece of work, while several applications that need custom role claims or organization-specific connections take longer. Confirm which milestones are included, such as validation in a test environment, production cutover and post-go-live checks, and who signs off each one. Your own change windows and the time it takes to reach the application vendor's SAML contacts often shape the schedule more than the configuration itself. Ask for the timeline to be tied to those milestones.
What does DeployOpen need from our team before a SAML integration starts?
Expect to provide access and information for each step of the work. You will need a list of applications with named owners, the SAML settings or metadata each service provider expects, and the attributes and roles each application requires. You also provide test accounts in staging, DNS and TLS details, network paths between Zitadel and each service provider, and a named approver for changes. Confirm with each application vendor whether it requires signed requests, encrypted assertions or a specific NameID format. Ask DeployOpen to list these inputs in the written scope so gaps are visible before work begins, and so your team knows who owns each one.
Can our internal team connect SAML applications to Zitadel without a partner?
Yes, an internal team with identity and SAML experience can do much of this work. The task is mainly configuration and testing, but it still requires people who can read SAML metadata, reason about assertions and debug audience or signature mismatches. Teams without that experience, or teams with many applications that document their SAML behavior poorly, often find that testing and rollout take most of the effort. Before deciding, count the applications, confirm each vendor's SAML support, and check how many people can take the work during your change windows. A partner is useful when you want the work defined in a written scope with documented handover to your staff.
How does attribute and role mapping affect SAML integration effort?
Attribute and role mapping often drives effort more than the basic sign-in flow. Each application expects specific attribute names, formats and group or role claims, and Zitadel must send them from its own users, organizations and project roles and grants. An application that needs only an email address and a display name is simple to map. An application that needs group membership translated into several application roles, with different rules per customer organization, needs design work, a test matrix and sign-off from the application owner. Ask for the mapping for each application to be listed in the scope, with the source of every attribute named.
How do multiple organizations and tenants change SAML integration work?
Each additional organization or instance can multiply the work. Zitadel organizes tenants as instances with full data isolation, and organizations inside an instance hold projects and users. If each customer organization needs its own identity provider, metadata or attribute rules, the configuration and testing repeat for each one. Confirm the tenancy model before scoping, including which applications sit in which organization and whether any service provider must accept signed metadata from more than one source. Review the Zitadel organizations documentation with your architects so the scope reflects how your tenants are actually separated.
Does certificate rotation add ongoing work after SAML go-live?
Yes, certificate rotation is recurring work that teams often underestimate. Signing certificates expire, and each service provider that trusts them may need updated metadata or a new certificate before the old one stops working. Plan a rotation calendar, record an owner for each application, and rehearse the change in staging before production. Ask whether the scope includes rotation support and documented steps, and whether that support is a one-time task or part of an ongoing retainer. Your internal team should know who approves the change and how a failed login is rolled back.
How DeployOpen scopes, delivers and supports Zitadel SAML connections
DeployOpen plans, implements and supports Zitadel as a SAML 2.0 identity provider for your applications inside infrastructure you control. Each engagement starts from a written scope that names every service provider, its metadata, the attributes it expects and the login flows it supports. Engagements are fixed-scope, and ongoing support is available as a retainer.
How we scope
- The written scope lists each SAML service provider, its entity ID, and the signed assertions it requires.
- Each application is checked for the SP-initiated only limitation, so the scope records which login flows it can use.
- Scope covers the Zitadel organizations, projects and roles that group each application, with deliverables and timelines agreed in writing.
How we build
- Metadata exchange is set up in both directions, with entity IDs, signing certificates and assertion consumer URLs verified before launch.
- Attribute mapping translates Zitadel user fields into the NameID and attribute names each application expects.
- Assertion signing settings are tested against each application's validation rules before any user signs in.
How we hand over
- Handover includes configuration records for each service provider, the attribute map, and the test evidence from each sign-in path.
- Runbooks cover certificate rotation for signing keys, metadata refresh and adding a new application to the existing setup.
- Where the engagement includes the Zitadel host, operators receive documentation for its PostgreSQL database and deployment method.
How we support
- Ongoing support is available as a retainer covering SAML certificate expiry, metadata changes and new application onboarding.
- Upgrades of Zitadel are planned as separate work, with release notes and a test run against each connected application first.
- Confirm each application's SAML profile before quoting, since support for SP-initiated only sign-in varies by product.
