Achtergrondinformatie over authenticatie en autorisatie

Authenticatie en autorisatie spelen een belangrijke rol in de meeste applicatiesuites. Deze pagina geeft een algemeen overzicht van de concepten en begrippen op dit gebied. Dit is handig als u nog weinig ervaring met dit onderwerp hebt of als u uw kennis wilt opfrissen. Als u vertrouwen hebt in uw basiskennis, kunt u verdergaan met Authenticatie en autorisatie in CXone.

Wanneer gebruikers inloggen bij een applicatiesuite, zoals CXone, worden meestal deze twee stappen achtereenvolgens uitgevoerd:

• Authenticatie – Zijn de gebruiker de personen die ze beweren te zijn?
• Autorisatie – Moeten de gebruikers na de authenticatie de toegang krijgen die ze hebben aangevraagd?

Alle gebruikers moeten worden geauthenticeerd en geautoriseerd voordat ze toegang krijgen tot CXone.

Vanuit het standpunt van de gebruikers zijn ze gewoon aan het inloggen. Authenticatie en autorisatie gebeuren achter de schermen om dit proces succesvol te laten verlopen. Aan het begin van een inlogprocedure zijn gebruikers niet geauthenticeerd. Dit betekent dat het systeem hun identiteit niet kent. Aan het einde van de inlogprocedure zijn ze zowel geauthenticeerd als geautoriseerd. Dit betekent dat het systeem weet wie ze zijn en tot welke bronnen ze toegang moeten hebben.

Een systeem doet het volgende om gebruikers te authenticeren en te autoriseren:

1. Bepalen welk authenticatieproces moet worden gebruikt (als er meerdere worden ondersteund). Veel systemen ondersteunen verschillende methoden. Systemen kunnen bijvoorbeeld gebruikers identificeren met een gebruikersnaam en wachtwoord, door middel van single sign-on (SSO) of met behulp van multi-factor authenticatie (MFA). Vaak kunnen gebruiker kiezen uit een lijst met authenticatieopties op de inlogpagina, maar systemen kunnen een bepaalde procedure verplicht stellen wanneer dat nodig is.

2. Gegevens voor de authenticatiegegevens verzamelen (bijvoorbeeld door gebruikers om hun gebruikersnaam en wachtwoord te vragen).

3. Inloggegevens verifiëren met behulp van een identiteitsprovider. Een identiteitsprovider is een afzonderlijk systeem dat informatie bijhoudt over gebruikers en hun identiteit (inclusief de inloggegevens).

4. De geauthenticeerde persoon of applicatie autoriseren. Nadat gebruikers zijn geauthenticeerd, gebruikt het systeem een autorisatieserver om gerichte toegang te verlenen aan de gebruiker. Het systeem verleent toegang aan de gebruiker op basis van de rol en de machtigingen van de gebruiker. Het systeem geeft gebruikers alleen toegang tot de functies die zij mogen bekijken of gebruiken.

Begrippen op het gebied van authenticatie

Identiteitsprovider

Identiteitsproviders (IdP's) zijn systemen die de identiteit van een gebruiker vaststellen. Er zijn twee soorten:

• Intern – Een onderdeel van het systeem waarop de gebruiker inlogt. Bijvoorbeeld: een gebruiker die inlogt bij Facebook gebruikt de Facebook IdP om zich te authenticeren bij de Facebook-applicatie.
• Extern – Los van het systeem waarop de gebruiker inlogt. Een gebruiker logt bijvoorbeeld in bij een smartphone-app met behulp van de Facebook IdP.

IdP's kunnen gehost of cloudgebaseerd zijn. Microsoft ADFS en Shibboleth zijn veelgebruikte gehoste IdP's. Microsoft Azure AD, Okta, en Ping zijn een paar van de veelgebruikte IdP's.

Authenticatieprotocollen

Authenticatieprotocollen verzorgen de communicatie tussen applicaties en IdP's, of tussen verschillende IdP's. OpenID Connect en SAML 2.0 zijn twee voorbeelden van authenticatieprotocollen. Sommige authenticatieprotocollen bieden extra functies, zoals versleuteling, maar applicaties maken niet altijd gebruik van deze functies. Wanneer een systeem een ingebouwde (interne) IdP gebruikt, zijn authenticatieprotocollen niet van belang.

Authenticatieflow

De meeste externe IdP's ondersteunen een van de onderstaande workflows, of beide, voor het authenticatieproces:

• SP-geïnitieerd: De authenticatie wordt geïnitieerd door de serviceprovider of applicatie. De gebruiker voert inloggegevens in en de applicatie maakt verbinding met een externe IdP om de identiteit te verifiëren. Dit is de meest gebruikte workflow.
• IdP-geïnitieerd: Gebruikers loggen eerst in bij de IdP, die eerst de gebruikers verifieert en daarna de gewenste applicaties start.

Federatief identiteitsmanagement

Federatief identiteitsmanagement wordt ook FIM of Federatie genoemd. Dit is een overkoepelende term voor het proces waarbij één externe IdP wordt gebruikt voor authenticatie ten behoeve van een of meer applicaties. Federatief identiteitsmanagement is in het algemeen beperkt in de tijd. Een gebruiker kan bijvoorbeeld één keer inloggen wanneer ze aan het werk gaat. Hierdoor wordt ze geauthenticeerd voor alle applicaties die ze die dag gebruikt. Maar de volgende dag moet ze weer inloggen om zich opnieuw te authenticeren, zelfs als ze de dag ervoor niet was uitgelogd.

Single sign-on

Single sign-on (SSO) wordt gebruikt om op basis van één login toegang te verlenen tot meerdere applicaties of systemen. Een gebruiker logt bijvoorbeeld in bij Microsoft 365 en krijgt dan toegang tot alle Microsoft-applicaties die zijn werkgever voor hem heeft geautoriseerd. Soms wordt de term SSO wel gebruikt in plaats van federatie, hoewel deze twee concepten niet hetzelfde zijn.

Multi-factor authenticatie

Multi-factor authenticatie (MFA) voegt een extra beveiligingsniveau toe aan de basisauthenticatie met behulp van gebruikersnaam en wachtwoord. MFA vereist dat de gebruiker een code invoert, een vraag beantwoordt of een token gebruikt voordat de IdP de identiteit van de gebruiker als geverifieerd beschouwt.

Vertrouwen

In de context van authenticatie verwijst 'vertrouwen' naar de informatie of kennis die door een applicatie of systeem wordt gedeeld met een externe IdP. Deze informatie creëert een relatie tussen de twee partijen, zodat ze weten dat ze kunnen vertrouwen op correcte en waarheidsgetrouwe communicatie met de ander. Hoe dit vertrouwen tot stand komt, verschilt afhankelijk van het authenticatieprotocol. De volgende voorbeelden zijn gebaseerd op OpenID Connect en SAML 2.0.

OpenID Connect

In OpenID Connect wordt vertrouwen gebaseerd op de uitgever. Een uitgever heeft een waarde die lijkt op een URL. Deze waarde legt uw identiteitsprovider vast. Google ondersteunt bijvoorbeeld OpenID Connect, met deze waarde als uitgever: https://accounts.google.com.

Op basis van de uitgever zijn er verschillende extra items die geconfigureerd moeten worden. In OpenID Connect wordt vertrouwen bijvoorbeeld gecreëerd door het ondertekenen van openbare/private certificaten. Hierbij wordt een industriestandaard met de naam JWKS gebruikt. Daarom is een deel van de geconfigureerde parameters bedoeld om te bepalen hoe deze publieke certificaten worden verkregen.

De meeste identiteitsproviders ondersteunen de detectie van deze informatie door een speciale string ("/.well-known/openid-configuration") toe te voegen aan de URL van de uitgever. Het Google-document voor deze detectie bevindt zich bijvoorbeeld hier: https://accounts.google.com/.well-known/openid-configuration.

SAML 2.0

In SAML 2.0 wordt vertrouwen gebaseerd op een entiteit-ID. In tegenstelling tot OpenID Connect is er geen sterke relatie tussen de entiteit-ID en andere configuratiewaarden. Er zijn verschillende configuratieparameters die worden gebruikt om vertrouwen op te bouwen met SAML 2.0.

• Entiteit-ID – Een waarde die door de applicatie of het systeem wordt bepaald om de identiteit te verifiëren

• Eindpunt-URL – Een door de externe IdP bepaalde waarde, die specificeert waar de authenticatieverzoeken worden ontvangen

• Bevestiging-URL – Een waarde die wordt bepaald door de applicatie of het systeem, die specificeert waarheen de externe IdP de authenticatieantwoorden moet sturen

• Certificaat – Wordt door de externe IdP gebruikt om het antwoord te ondertekenen