What is a Service Provider?

A Service Provider (SP), in single sign-on, is the system that trusts an identity provider (IdP) to authenticate a user, then grants access based on the IdP’s assertion. Versa Director, Concerto, and SSE Gateways each act as the SP, identified by a unique SP entity ID and assertion consumer service URL.

Key takeaways

• The SP trusts an IdP’s assertion instead of checking credentials itself.
• SP-initiated SSO starts at the login page; IdP-initiated starts at the IdP.
• Versa Director, Concerto, and SSE Gateways each register as a distinct SP.
• An SP entity ID and ACS URL uniquely identify each Versa SP integration.
• SAML and OpenID Connect both use an SP role, tested against four IdPs.

On this page: Why it matters · How it works · Types · Service providers & Versa · FAQ

Why is a service provider important?

Single sign-on exists to stop every application from running its own login system. Without a clear SP role, each product – Director, Concerto, a portal – would need its own password database, its own multi-factor enrollment, and its own process for disabling a departing employee’s access. The SP role fixes that by delegating the authentication decision to one trusted identity provider, so the application only has to trust a signed assertion, not manage credentials itself.

That separation is also a security control. Centralizing authentication at the IdP means multi-factor enforcement, password policy, and account lifecycle happen in one place instead of being replicated – and potentially forgotten – across every SP an organization runs. For administrators juggling Director, Concerto, and Titan Portal logins, the SP role is what lets one IdP credential open all of them under one policy.

What is a service provider?

Mechanically, the SP is the half of the SSO handshake that never sees a password. In SP-initiated SAML, the SP builds an authentication request and redirects the browser to the IdP; the IdP authenticates the user and posts a signed assertion back to the SP’s assertion consumer service (ACS) URL; the SP validates the signature and audience, then logs the user in. In IdP-initiated flows, the sequence starts at the IdP instead, which sends the assertion to the SP directly.

Two identifiers make an SP addressable: the SP entity ID (also called the audience URI or SP issuer), which names the SP inside the assertion, and the ACS URL, which tells the IdP where to deliver the login response.

Types of service providers

Versa’s SSO implementation defines the SP role two ways, matching its two supported protocols. A SAML service provider exchanges signed XML assertions with the IdP, identified by an SP entity ID and ACS URL, and can require a specific authentication context – password, certificate, or multi-factor. An OpenID Connect service provider – commonly called a relying party in OIDC terminology, though Versa’s own screens still label it a service provider – registers a client ID and secret with the IdP instead, exchanging a signed token through authorize, token, userinfo, and revoke endpoints.

Both variants do the same job – trust the IdP, validate its response, log the user in – differing only in protocol, credential format, and the identifiers the SP registers.

Service providers & Versa

Versa Director, Concerto, and SSE Gateways all take the SP role, tested against ADFS, Azure, Okta, and Ping Identity. Versa’s convention registers the SP entity ID as http://versa-networks.com/sp, with SAML responses delivered to an ACS URL such as https://<director-ip>/versa/sso/loginConsumer, and OpenID Connect responses to a parallel /versa/sso/openid/loginConsumer endpoint. See Configure Single Sign-On for Concerto for the full Okta-based walkthrough.

SSO can be scoped per tenant: a connector mode of None, Default IdP Connector, or Single IdP Connector controls whether system and tenant users authenticate through a given SP, and each organization binds to its own IdP connector. Manage Users covers the separate, provider-administrator sense of “Service Provider” that governs who configures these settings.

Frequently asked questions

What is the difference between SP-initiated and IdP-initiated SSO?

In SP-initiated SSO, the flow starts at the SP’s own login page – clicking “Login with SSO” on Concerto or Director – which redirects to the IdP. In IdP-initiated SSO, the user starts at the IdP’s dashboard and is redirected straight into the SP.

What is an SP entity ID?

The SP entity ID is a unique URI identifying the service provider to the identity provider during SAML federation – Versa Director and Concerto register as http://versa-networks.com/sp. The IdP uses it, with the assertion consumer service URL, to route and validate login responses.

Which identity providers work with Versa’s service provider role?

Versa’s SSO implementation has been tested against ADFS, Azure, Okta, and Ping Identity as identity providers, over SAML or OpenID Connect. Any standards-compliant IdP supporting one of those protocols can typically federate with Versa Director, Concerto, or an SSE Gateway as the SP.

Does OpenID Connect use the same service provider role as SAML?

Conceptually yes – Versa’s documentation labels both roles “service provider,” though OpenID Connect more commonly calls it a relying party. Instead of an SP entity ID and ACS URL, an OpenID Connect SP registers a client ID, secret, and redirect URIs with the IdP.

Is “Service Provider” in Concerto user management the same as the SSO service provider role?

No. Concerto also uses “Service Provider” for the administrator role managing tenants and infrastructure (Service Provider Administrator, Service Provider view) – an MSP concept unrelated to SAML or OpenID Connect, where “service provider” here names the system consuming an IdP’s assertion.

More on service providers

If you want to learn more, these are sources we trust.

Related terms

If you’re reading about service providers, these are worth looking at next.