Azure Single Sign-On (SSO) with a Third-Party Application — SAML Authentication Setup
This implementation service configures Azure Single Sign-On (SSO) with a third-party application that supports SAML authentication, so selected users can authorize on the desired service using Entra ID credentials. It is for organizations that have administrative access to both their company tenant and the third-party service they want to connect to Azure with SSO.
What this engagement is
Single sign-on (SSO) means users do not need to sign in to every application they use with separate credentials. A user logs into Entra ID once, and those credentials are used for other applications such as Sales Force, Slack, Zendesk, and many others. SSO-based authentication systems are often referred to as modern authentication. Modern authentication and single sign-on fall into a category of computing called Identity and Access Management (IAM).
Success criteria
What you receive
How the work unfolds
Confirm the target third-party application, business owner, test users, preferred implementation window, required administrator access, and communication approach for affected users.
Gather the application’s SAML SSO requirements, including entity ID, reply URL/ACS URL, sign-on URL, certificate requirements, user identifier format, required claims or attributes, and any vendor-specific setup instructions.
Access the client Microsoft 365/Azure tenant with approved administrative permissions and review the Entra ID configuration needed to create or configure the Enterprise application.
Access the third-party application administration portal with approved permissions and locate the SAML/SSO configuration area required for the integration.
Create and configure the Entra ID Enterprise application, exchange SAML metadata or configuration values between Entra ID and the third-party service, configure required claims and certificate settings, and assign the selected users or groups.
Test the SSO sign-in flow with selected users, validate successful authentication to the third-party service using Entra ID credentials, troubleshoot configuration issues, and confirm readiness for project closeout.
Prerequisites
Who does what
IT Partner
- Check prerequisites for SSO implementation
- Create an Enterprise application for the required service
- Configure this application according to the requirements
- Configure the required third-party service
- SSO enabling and testing
Your team
- Coordinate Client resources and staff schedules
- Provide a dedicated point of contact responsible for working with IT Partner
- Coordinate any outside vendor resources and schedules
- Provide administrative access to Microsoft 365 tenant
- Notify users about new services
- Review and approve engagement deliverables in a timely manner
What's not included
Limitations & technical notes
Frequently asked questions
What does the Azure Single Sign-On (SSO) with a Third-Party Application service include?
This service configures Azure Single Sign-On with a third-party application that supports SAML authentication, so selected users can sign in to that application using Entra ID credentials. IT Partner checks prerequisites, creates and configures the required Enterprise application in Azure, configures the third-party service, enables SSO, tests it, and provides a project closeout report.
What is the main outcome of this SSO implementation?
The target outcome is that SSO is enabled in Azure for the required third-party application and selected users can authorize on that service using Entra ID credentials. This is validated during the engagement through SSO testing before project closeout.
Which third-party applications can be connected with this service?
This service applies to third-party applications that support SAML authentication and can be configured for SSO with Azure/Entra ID. Common examples of SSO-enabled services include applications such as Salesforce, Slack, and Zendesk, but the specific application must be reviewed for compatibility before implementation.
What are the prerequisites for this Azure SSO service?
You need administrative access to your company tenant, administrative access to the third-party service you want to connect, and the third-party service must support SAML authentication. These prerequisites matter because IT Partner must configure both the Azure Enterprise application and the third-party application settings for SSO to work.
Do we need admin access to both Microsoft 365/Azure and the third-party application?
Yes, administrative access is required for both your company tenant and the third-party service being connected. Without both sides of access, IT Partner may not be able to create the Enterprise application, exchange SAML configuration details, or complete the third-party service configuration.
Does this service use Microsoft Entra ID credentials for login?
Yes, the purpose of the service is to allow selected users to authorize on the desired third-party service using Entra ID credentials. In this context, Azure SSO means users authenticate through Entra ID rather than maintaining separate credentials for that application.
Is this service for SAML-based SSO only?
Yes, the stated prerequisite is that the third-party service supports SAML authentication. If the application uses a different authentication method or has special integration requirements, the scope should be confirmed with IT Partner before purchasing.
What happens during the engagement?
The engagement typically includes a kickoff meeting, collection of required project data, connection to the client tenant, connection to the third-party service, SSO configuration, and verification with issue fixing. The plan may vary depending on your needs, because each third-party application can have different SAML configuration requirements.
What deliverables do we receive at the end of the project?
Deliverables include prerequisite checks, creation of the required Enterprise application, configuration of the Enterprise application, configuration of the third-party service, SSO enablement and testing, and a project closeout report. The closeout report indicates final project status, acceptance criteria matching, any outstanding issues, and the final budget.
What is IT Partner responsible for in this SSO implementation?
IT Partner is responsible for checking prerequisites, creating the Enterprise application for the required service, configuring that application according to requirements, configuring the third-party service, and enabling and testing SSO. These tasks cover the technical implementation work needed to connect the third-party application to Azure SSO.
What is the client responsible for during the project?
The client is responsible for coordinating internal resources and schedules, providing a dedicated point of contact, coordinating outside vendor resources if needed, providing administrative access to the Microsoft 365 tenant, notifying users about new services, and reviewing and approving deliverables in a timely manner. These responsibilities are important because SSO setup depends on access, timely decisions, and coordination with the application owner or vendor.
Will this service migrate our application data to Azure?
No, migration of data to Azure—such as applications, mail, virtual machines, databases, or files—is not included in this service. Data migration can be purchased as an additional service if needed.
Does this service include workstation configuration or installing user applications?
No, workstation configuration is not included. Installation of user programs on virtual machines is also listed as outside the project scope, except for the office suite, and this setting can be discussed individually. This service is focused on configuring Azure SSO with a supported third-party application, not endpoint setup.
Will users experience downtime during SSO configuration?
The service content does not specify a guaranteed downtime window or business impact. Because SSO changes affect authentication to the third-party application, timing and user notification should be coordinated with IT Partner and the client’s point of contact before implementation.
How are users selected for SSO access?
The service outcome refers to selected users being able to authorize on the desired service using Entra ID credentials. The exact user selection, assignment approach, and rollout timing should be confirmed during data collection and configuration, because they depend on the application and tenant requirements.
How long does the SSO implementation take?
The listed duration for this service is 2 days. The plan may vary depending on your needs, including the third-party application, administrative access availability, vendor coordination, and how quickly required information is provided.
How does pricing work for this service?
The listed price for this service is $350. The project closeout report includes the final budget, and any work outside the stated scope—such as data migration or more extensive documentation—may require an additional fee.
What happens if the third-party application has unusual SAML requirements?
IT Partner configures the Azure Enterprise application and the required third-party service according to the application requirements, then verifies and fixes issues within the project scope. If the application needs work beyond standard SAML SSO configuration, the specifics should be reviewed with IT Partner because the plan may vary depending on your needs.
What documentation is included after implementation?
The included documentation is a project closeout report showing final project status, acceptance criteria matching, any outstanding issues, and the final budget. More extensive documentation beyond the closeout report is not included by default and can be provided for an additional fee.
What happens after SSO is enabled and tested?
After SSO is enabled and tested, IT Partner provides project closeout information documenting the final status, acceptance criteria, outstanding issues if any, and final budget. The client should review and approve deliverables in a timely manner and notify users about the new sign-in experience.