Service Provider
The term service provider can have multiple meanings. Often, the term refers to online providers such as managed service providers, payment service providers, or internet service providers. And HelloID is an example of an IAM service provider.
In this article, we focus specifically on Service Providers (SP) that work with so-called Identity Providers (IdP) in a trust relationship to centralize, improve, and simplify user authentication.
What is a Service Provider?
In this context, a Service Provider is a cloud application or website that does not perform user authentication itself, but delegates it to an Identity Provider. That is a central authentication platform that manages all required identification and authentication data. Both systems must trust each other, and therefore, they form a so-called trust relationship.
A trust relationship is used primarily in organizations with many users and multiple cloud applications. Decentralized management of login credentials is complex, time-consuming, and error-prone, whereas a central authentication platform resolves these issues. As an additional benefit for users, you can offer Single Sign-On (SSO). Once a user has been authenticated at the request of Service Provider 1, it does not need to be repeated for Service Provider 2. The user logs in only once.
What Does a Service Provider Do?
How does a trust relationship work for the Service Provider? We explain it with two scenarios. The first describes how the traditional standalone sign-in procedure works. Then we outline the authentication process within a collaboration, where the application acts as a Service Provider in such a trust relationship.
Direct Authentication
A user attempts to access the application.
The application detects that the user is not signed in and navigates the user to the login screen.
There, the user enters credentials such as a username and password.
The application verifies the user’s identity. If authentication is successful, the user is granted access.
Authentication at the IdP (application acts as SP within a trust relationship)
A user attempts to access the application.
It detects that the user is not signed in and, in its role as Service Provider, sends an authentication request to the IdP.
The user is redirected to the IdP’s login page. There, the user enters credentials such as a username and password.
The IdP verifies identity and, upon successful verification, generates an authentication token. This is an encrypted digital access token.
The user is routed back to the Service Provider with this token.
The Service Provider validates the token and grants the user access.
Access, therefore, occurs indirectly. There is a trust relationship between the Identity Provider and the Service Provider, so the application grants access based on the authentication token it receives from the Identity Provider.
SSO with Multiple Service Providers
With Single Sign-On (SSO) implemented, users do not need to sign in to each application. If a user has already authenticated through the Identity Provider for Service Provider 1, authentication for Service Provider 2 can occur automatically. The scenario is described below.
Access to Service Provider 2 with SSO
The user’s authentication for Service Provider 1 has already been successfully completed (see previous section).
The same user then attempts to access Service Provider 2.
It detects that the user is not signed in and therefore sends an authentication request to the IdP.
The IdP sees that the user already has an active session with Service Provider 1. The user, therefore, does not need to be verified again.
Instead, an authentication token is created immediately and sent to Service Provider 2.
It validates the token and grants the user access.
The user is therefore signed in to Service Provider 2 without having to perform another authentication step. This functionality is optional. You can also choose to have users sign in to each Service Provider separately. However, such a trust relationship with a central Identity Provider is particularly well-suited for SSO.
IAM Integrations with Service Providers
Many organizations use an Identity Provider to handle centralized authentication and Single Sign-On for their users. A commonly used solution is Entra ID.
You can then use an IAM solution such as HelloID to provide that authentication platform with the required identification and authentication data (credentials). You can also provision additional user attributes, such as a person’s job title or department. During authentication, this data can be passed to the Service Provider, which uses it locally to determine the user’s permissions.
With that mechanism, you can generally set user permissions only at a high level. For example, for Electronic Patient Records or case management systems, organizations often want to define permissions much more granularly based on multiple attributes and other data. This is often only possible when you manage authorization directly from the IAM platform through a direct integration with the Service Provider. To connect such Service Providers to the IAM platform, HelloID offers an extensive set of connectors.
Want to Learn More About Connecting Service Providers?
Want to learn more about how different systems can be connected to your HelloID IAM environment by using connectors? You can find more in our connectors catalog.