How to connect your SaaS application?
Nowadays software companies publish their software as a service. That's easier to maintain on their end and easier to use by the customer. But what if you want to use your company credentials to log in to this application? How do you connect a SaaS application to your infrastructure? If you have a hybrid infrastructure there are lots of possibilities. Most companies have Active Directory, a Security Token Service (STS) like Active Directory Federation Services (ADFS), or use Entra ID (formerly known as Azure Active Directory). Not to mention the endless hybrid possibilities.
You should start asking yourself the question: Do you want to log in with company credentials? If not, the service provider (in federation terminology the company who publishes their software as a service is often called a service provider) can send you the credentials of their software and you're good to go. Which authentication options does the service provider provide to you? Unfortunately, some service providers (2021!) don't offer federation possibilities to their application but luckily as we are, most of them do.
If you want to federate with a service provider and want to bring your credentials you are the identity provider. You will provide your credentials to the service provider. You can do this by creating a federation trust with the service provider by using an STS like ADFS or using Entra ID. If you use both products, you should prefer Entra ID. Entra ID is more than an STS, it's an identity and access management service. With Entra ID you can control access to your applications and application resources. Entra ID gives you tools to automatically protect user identities and credentials and meet your access governance requirements.
Depending on the requirements from the service provider you can add the application to your Entra ID. That means you need to create an application object through the application registration section in the Azure portal.
A little sidestep;
If you are familiar with the Azure portal, you noticed there are two application blades: the application registration blade and the Enterprise application blade. So why create an application registration instead of an enterprise application?
Well, in a nutshell, when you register an application in Entra ID, two objects are created in your Entra ID tenant:
- An application object
- A service principal object
The application object gives you control over three aspects of the concerning application: how the service can issue tokens to access the application, resources that the application might need to access, and the actions that the application can take.
The Enterprise application blade is more like the management section for service principals. To access resources that are secured by an Entra ID tenant, the entity that requires access must be represented by a security principal. This is true for both users (user principal) and applications (service principal).
The security principal defines the access policy and permissions for the application in the Entra ID tenant. This enables core features such as authentication of the user/application during sign-in, and authorization during resource access.
/A little sidestep
When creating an application registration, Entra ID assigns a unique application (client) ID to your application registration. Together with the application (client) ID, directory (tenant) ID, and client secret, the service provider (Tenant A in the picture below) has an endpoint to publish their software to your Entra ID. Or the other way around; You are allowed to access the service provider's application through the published application in your home tenant (Tenant B).
When you are the service provider and developing applications, and publishing them through Entra ID, you can choose the application to be single-tenant or multi-tenant during the app registration in the Azure portal.
- Single-tenant applications are only available in the tenant they are registered in, also called their home tenant. It's a single instance of the software serving a single customer.
- Multi-tenant applications are available to users in both their home tenants and other tenants. It's a single instance of the software serving multiple customers.
When a user wants to sign in to an application in Entra ID, the application must be represented in the home tenant of the user. This allows the users' organization to apply policies or specific access controls. For a single-tenant application, the registration is fairly simple; it’s the one that happens when you register the application in the Azure Portal.
For a multi-tenant application, the initial registration for the application takes place in the Entra ID tenant (Tenant A in the picture below) used by the service provider. When a customer, from a different tenant (Tenant B in this case), signs into the application for the first time, Entra ID asks them to consent (Step 3). They need to consent to the permissions requested by the application. If they consent, then a representation of the application, a service principal, is created in the user’s home tenant (Step 4). A delegation is also created in the user's home tenant that registers the user’s consent to the particular application. You can find this in the permission section on the Enterprise application object.
All this is possible when the service provider and the identity provider use Entra ID. But if you don’t have Azure Entra ID and want to connect to a service provider which is running a multi-tenant or single-tenant application from Entra ID, what then?
I will write this down in the next article, stay tuned…
