Hoe sluit je een SaaS-applicatie aan?
Tegenwoordig publiceren softwarebedrijven hun software ‘as a service’. Dat is gemakkelijker te onderhouden aan hun kant, en gemakkelijker te gebruiken voor de klant. Maar wat als je je bedrijfsgegevens wilt gebruiken om in te loggen op deze applicatie? Hoe sluit je dan een SaaS-applicatie aan op jouw infrastructuur? Als je een hybride infrastructuur hebt zijn er veel mogelijkheden. De meeste bedrijven hebben Active Directory, een Security Token Service (STS) zoals Active Directory Federation Services (ADFS), of gebruiken Entra ID (voorheen Azure Active Directory). Om nog maar te zwijgen over de eindeloze hybride mogelijkheden.
Je moet jezelf de vraag stellen: Wil je inloggen met bedrijfsreferenties? Zo niet, dan kan de serviceprovider (in federation terminologie wordt het bedrijf dat zijn software als een service uitgeeft vaak een serviceprovider genoemd) je de credentials van hun software toesturen en je bent klaar om te beginnen. Welke authenticatie opties biedt de serviceprovider verder aan jou? Jammer genoeg bieden sommige serviceproviders geen federatie mogelijkheden aan hun applicatie (en dat in 2021!), maar gelukkig doen de meesten dat wel.
Als je wilt federeren met een serviceprovider en jouw credentials wilt meenemen, ben je de identity provider. Je zult je credentials aan de serviceprovider verstrekken. Je kunt dit doen door een federation trust aan te maken met de serviceprovider, door gebruik te maken van een STS zoals ADFS, of door Entra ID te gebruiken. Als je beide producten gebruikt, dan zou je de voorkeur moeten geven aan Entra ID. Entra ID is meer dan een STS, het is een identity en access managementservice. Met Entra ID kan je de toegang tot jouw applicaties en applicatie resources beheren. Entra ID geeft je tools om gebruikersidentiteiten en credentials automatisch te beschermen en te voldoen aan je access governance eisen.
Afhankelijk van de vereisten van de serviceprovider kan je de applicatie toevoegen aan jouw Entra ID. Dat betekent dat je een applicatie object moet aanmaken via de applicatie registratie sectie in de Azure portal.
Een kleine zijstap;
Als je bekend bent met de Azure portal heb je gemerkt dat er twee applicatie blades zijn: de applicatie registratie blade en de Enterprise applicatie blade. Dus waarom een applicatie registratie aanmaken in plaats van een enterprise applicatie?
In een notendop: als je een applicatie registreert in Entra ID, worden er twee objecten aangemaakt in jouw Entra ID tenant:
- Een applicatie object
- Een service principal object
Het applicatie-object geeft je controle over drie aspecten van de betreffende applicatie: hoe de service tokens kan uitgeven om toegang te krijgen tot de applicatie, resources waar de applicatie mogelijk toegang tot dient te krijgen, en de acties die de applicatie kan ondernemen.
De Enterprise application blade lijkt meer op het management gedeelte voor service principals. Om toegang te krijgen tot resources die zijn beveiligd door een Entra ID tenant, moet de entiteit die toegang nodig heeft worden vertegenwoordigd door een security principal. Dit geldt zowel voor gebruikers (user principal) als voor applicaties (service principal).
De security principal bepaalt het toegangsbeleid en de machtigingen voor de applicatie in de Entra ID tenant. Dit maakt kernfuncties mogelijk zoals authenticatie van de gebruiker/applicatie tijdens het aanmelden, en autorisatie tijdens toegang tot resources.
/Een kleine zijstap
Bij het aanmaken van een applicatie registratie, wijst Entra ID een unieke applicatie (client) ID toe aan jouw applicatie registratie. Samen met de applicatie (client) ID, directory (tenant) ID en client secret, heeft de serviceprovider (Tenant A in de afbeelding hieronder) een end-point om hun software te publiceren in jouw Entra ID. Of andersom: Je krijgt toegang tot de applicatie van de serviceprovider via de gepubliceerde applicatie in jouw home tenant (Tenant B).
Wanneer je de serviceprovider bent, applicaties ontwikkelt en deze publiceert via Entra ID, kan je tijdens de app registratie in de Azure portal kiezen om de applicatie single-tenant of multi-tenant te maken.
- Single-tenant applicaties zijn alleen beschikbaar in de tenant waarin ze zijn geregistreerd, ook wel hun home tenant genoemd. Het is een enkele instantie van de software die een enkele klant bedient.
- Multi-tenant applicaties zijn beschikbaar voor gebruikers in zowel hun home tenant als andere tenants. Het is een enkele instantie van de software die meerdere klanten bedient.
Wanneer een gebruiker zich wil aanmelden bij een applicatie in Entra ID, moet de applicatie vertegenwoordigd zijn in de home tenant van de gebruiker. Hierdoor kan de organisatie van de gebruiker beleidsregels of specifieke toegangscontroles toepassen. Voor een single-tenant applicatie is de registratie vrij eenvoudig; dit gebeurt wanneer je de applicatie registreert in de Azure Portal.
Voor een multi-tenant applicatie, vindt de initiële registratie voor de applicatie plaats in de Entra ID tenant (Tenant A in de afbeelding hieronder) die wordt gebruikt door de serviceprovider. Wanneer een klant, van een andere tenant (Tenant B in dit geval), voor de eerste keer inlogt in de applicatie, vraagt Entra ID hen om toestemming (Stap 3). Ze moeten toestemming geven voor de permissies die door de applicatie worden gevraagd. Als ze toestemming geven, dan wordt een representatie van de applicatie, een service principal, aangemaakt in de home tenant van de gebruiker (Stap 4). Er wordt hier ook een delegatie aangemaakt die de toestemming van de gebruiker voor de specifieke toepassing registreert. Je kunt dit vinden in de toestemmingssectie op het Enterprise applicatie object.
Dit is allemaal mogelijk wanneer de serviceprovider en de identity provider Entra ID gebruiken.
Maar als je geen Azure Entra ID hebt en verbinding wilt maken met een service provider die een multi-tenant of single-tenant applicatie draait vanuit Entra ID, wat dan?
Ik zal dit in het volgende artikel opschrijven, stay tuned...