Authenticatie en autorisatie in CXone

Deze pagina bevat specifieke informatie over de manier waarop authenticatie en autorisatie werken in CXone. Als dit de eerste keer is dat u met dit onderwerp werkt, moet u eerst algemene informatie lezen over de concepten en begrippen op het gebied van authenticatie en autorisatie.

Nadat u dit informatiemateriaal hebt doorgenomen, ben u klaar om het volgende te doen:

• CXone-authenticatie configureren met de ingebouwde identiteitsprovider
• CXone-authenticatie configureren met een externe identiteitsprovider

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.

Het configureren, testen en valideren van authenticatie is vaak ingewikkeld. Om authenticatie in CXone te kunnen configureren, moet u het volgende weten:

• Hoe authenticatie werkt in CXone

• De ingebouwde identiteitsprovider van CXone

• Externe identiteitsproviders

• Verschillen tussen de authenticatie van menselijke gebruikers en applicatiegebruikers

U moet ook weten hoe autorisatie werkt in het CXone-platform.

Deze afbeelding laat zien hoe CXone gebruikers authenticeert en autoriseert:

1. Een gebruiker krijgt toegang tot CXone via een ondersteunde webbrowser.

2. CXone vraagt om de inloggegevens van de gebruiker.

3. De gebruiker voert de inloggegevens in.

4. CXone verifieert de gegevens bij een identiteitsprovider (IdP). CXone heeft een ingebouwde IdP, maar kan ook werken met een externe IdP.

5. Nadat de gebruiker is geauthenticeerd, geeft de CXone-autorisatieserver toegang tot het CXone-platform. CXone ondersteunt geen externe autorisatiesystemen.

Authenticatie met de ingebouwde identiteitsprovider

De ingebouwde IdP van CXone authenticeert gebruikers met behulp van een gebruikersnaam en wachtwoord. Elke gebruikersnaam moet uniek zijn voor uw organisatie. U kunt eventueel multi-factor authenticatie (MFA) toevoegen als extra beveiligingslaag.

Applicatiegebruikers

Soms moeten applicaties toegang hebben tot functies en functionaliteit van CXone. CXone beschouwt deze applicaties, zoals bots en intelligente virtuele agents (IVA's), als 'applicatiegebruikers'. Applicatiegebruikers worden alleen ondersteund met ingebouwde authenticatie. Bovendien maken applicatiegebruikers geen gebruik van inlogauthenticators. In plaats daarvan gebruiken ze toegangssleutels.

Gebruikerslogin met ingebouwde authenticatie

Gebruikers zien eerst een scherm waarin om hun gebruikersnaam wordt gevraagd. Zolang CXone de gebruikersnaam nog niet weet, kan het systeem niet om verdere inloggegevens vragen. CXone kan pas om wachtwoorden of MFA-tokens vragen als het systeem weet welke gebruiker probeert in te loggen.

Nadat de gebruiker de gebruikersnaam heeft ingevoerd en op Volgende heeft geklikt, verschijnt een nieuw venster dat vraagt om het wachtwoord van de gebruiker. Nadat de gebruiker het juiste wachtwoord heeft ingevoerd en op Inloggen heeft geklikt, zal CXone de gebruiker authenticeren en toegang geven tot het systeem.

Dit venster ziet er iets anders uit voor gebruikers voor wie multi-factor authenticatie (MFA) is geconfigureerd. Nadat de gebruiker de gebruikersnaam heeft ingevoerd en op Volgende heeft geklikt, verschijnt een nieuw venster dat vraagt om het wachtwoord en het MFA-token van de gebruiker. Nadat de gebruiker het juiste wachtwoord en een geldig token heeft ingevoerd, klikt de gebruiker op Inloggen. CXone authenticeert de gebruiker en verleent de gebruiker toegang tot het systeem.

Wachtwoordbeheer met ingebouwde authenticatie

U kunt de wachtwoordcriteria aanpassen met behulp van inlogauthenticators. Met een inlogauthenticator kunt u het volgende instellen:

• Het aantal tekens dat is vereist in een wachtwoord

• De soorten tekens die zijn vereist in een wachtwoord

• Het aantal dagen voordat de gebruiker een nieuw wachtwoord moet instellen

• Het aantal mislukte wachtwoordpogingen dat is toegestaan voordat de account wordt vergrendeld

• Het aantal wachtwoorden dat CXone onthoudt, zodat gebruikers dezelfde wachtwoorden niet opnieuw kunnen gebruiken

CXone heeft een standaard inlogauthenticator die u kunt gebruiken als u geen aangepaste inlogauthenticators nodig hebt. U moet deze standaardauthenticator wel nog toewijzen aan de gebruikers die de inlogauthenticator moeten gebruiken.

U kunt zoveel aangepaste inlogauthenticators instellen als u wilt. U kunt bijvoorbeeld extra complexe wachtwoorden vereisen voor gebruikers die toegang hebben tot gevoelige informatie. Wanneer u een authenticatievereiste voor een gebruikersaccount wilt aanpassen, moet u hiervoor een nieuwe inlogauthenticator maken. Wijzigingen in authenticators gelden voor de desbetreffende gebruikers wanneer ze de eerstvolgende keer inloggen.

U kunt ook multi-factor authenticatie (MFA) configureren met behulp van aangepaste inlogauthenticators. MFA versterkt de beveiliging door een extra authenticatielaag toe te voegen. U kunt uw gebruikers bijvoorbeeld eerst authenticeren met een gebruikersnaam en wachtwoord. Vervolgens kunt u ze een extra authenticatiestap laten uitvoeren door middel van een code die naar hun mobiele apparaat wordt gestuurd. Deze codes worden meestal MFA-tokens genoemd.

CXone ondersteunt de twee belangrijkste vormen van MFA:

• Tijdgebaseerd – Wordt meestal gebruikt door softwarematige authenticators, zoals Google
• Op basis van een teller – Wordt meestal gebruikt door hardwarematige 'tokens' (apparaatjes)

U kunt MFA voor inlogauthenticators inschakelen door één selectievakje aan te vinken. Maar de specifieke informatie over gebruikers, hun MFA-instellingen en hun identiteit wordt bijgehouden in de individuele medewerkersaccounts.

Inlogauthenticators en beveiligingsprofielen zijn volledig van elkaar gescheiden. Dit betekent dat de authenticatiemethode van een medewerker helemaal los staat van de onderdelen van CXone die de medewerker kan gebruiken.

Authenticatie met een externe identiteitsprovider

Wanneer u bij een systeem inlogt met een account van een andere website, maakt u gebruik van 'externe authenticatie' of 'federatie'. U kunt bijvoorbeeld met uw Google-account inloggen bij een app op uw smartphone.

Bij externe authenticatie (soms 'federatie' genoemd) wordt een externe identiteitsprovider (IdP) gebruikt om gebruikers te authenticeren. De externe IdP werkt samen met de identiteitsprovider van CXone om de gebruiker te authenticeren. Voor deze samenwerking maken beide IdP's gebruik van authenticatieprotocollen.

Externe IdP's

CXone ondersteunt zowel gehoste als cloudgebaseerde identiteitsproviders.

U moet bekend zijn met uw identiteitsprovider. Zo niet, overleg dan met het team van uw organisatie dat de authenticatie beheert. Het configureren van federatie kan lastig zijn als de juiste mensen er niet bij betrokken zijn. Mogelijk heeft uw organisatie processen opgezet voor het integreren van systemen zoals CXone met uw identiteitsprovider. Het is uw verantwoordelijkheid dat deze processen worden gevolgd en dat u voldoet aan uw specifieke beveiligingsbehoeften. Het NICE CXone-team staat klaar om u te ondersteunen.

Authenticatieprotocollen

Authenticatieprotocollen ondersteunen de communicatie en het vertrouwen tussen verschillende IdP's. CXone ondersteunt de volgende authenticatieprotocollen:

• OpenID Connect
• SAML 2.0

OpenID Connect biedt meer functionaliteit en is gemakkelijker te ondersteunen. Voordelen zijn onder andere:

• Industriestandaard technologie

• Ondersteunt naadloze IdP-integratie die transparant is voor de gebruiker

• Ondersteunt een scala aan opties voor multi-factor authenticatie (MFA)

• Schaalbaar fundament voor een platform-servicemodel

OpenID Connect valideert authenticaties met openbare/private certificaatondertekening op basis van de industriestandaard JWKS. Daarom bepaalt de configuratie van OpenID Connect de manier waarop de publieke certificaten worden verkregen. Vertrouwen in de certificaatuitgever wordt gecreëerd met behulp van een client-ID en een geheim.

SAML 2.0 is een oudere technologie die soms integratieproblemen kan veroorzaken. Dit protocol wordt echter nog op grotere schaal gebruikt dan OpenID Connect. Uw organisatie heeft mogelijk richtlijnen voor het protocol dat moet worden gebruikt. Over het algemeen bieden ze beide een vergelijkbare gebruikerservaring en onderliggende beveiliging.

Zowel OpenID Connect als SAML 2.0 ondersteunen authenticatie op initiatief van de serviceprovider (SP-geïnitieerd). Dit is een vertrouwde workflow en een model dat door veel bekende apps en websites wordt gebruikt. De gebruikerservaring is als volgt:

• Gebruikers gebruiken hun inloggegevens om bij CXone in te loggen.
• CXone gebruikt zijn ingebouwde IdP om met uw externe IdP te communiceren ten behoeve van de verificatie van de identiteit van de gebruiker.
• CXone gebruikt zijn ingebouwde autorisatie om de toegangsniveaus van de geauthenticeerde gebruiker te controleren.
• CXone verleent de juiste toegang aan de geauthenticeerde en geautoriseerde gebruiker

SAML 2.0 ondersteunt ook de minder vaak gebruikte workflow voor authenticatie op initiatief van de identiteitsprovider (IdP-geïnitieerd). Met deze workflow voeren uw gebruikers hun inloggegevens in bij uw identiteitsprovider. Vervolgens wordt CXone gestart door de identiteitsprovider.

Bij SAML 2.0, ondersteunt CXone alleen het ondertekenen van het bericht/de respons, niet de bevestiging.

Uw gebruikers zijn waarschijnlijk bekend met (een van) deze workflows. Als u gebruikmaakt van SAML 2.0, houd dan rekening met de beperkingen van beide workflows. Deze worden verder besproken in de volgende paragraaf. OpenID Connect maakt altijd gebruik van authenticatie op initiatief van de serviceprovider (SP-geïnitieerd).

CXone biedt geen ondersteuning voor aanvullende versleuteling die wordt aangeboden door sommige authenticatieprotocollen.

De details van de configuratie verschillen afhankelijk van de identiteitsprovider en het authenticatieprotocol dat u kiest. Het is niet mogelijk om hier alle mogelijke combinaties van IdP's en authenticatieprotocollen te behandelen, maar enkele veelvoorkomende scenario's worden hieronder besproken.

De combinatie evalueren

De CXone-suite ondersteunt niet elke denkbare combinatie van applicatie, externe IdP en authenticatieprotocol. In sommige situaties is er geen ondersteuning. In andere situaties zijn er beperkingen met workarounds. Het is moeilijk om alle potentiële problemen voor elke combinatie en scenario te laten zien. Maak daarom een testconfiguratie met uw identiteitsprovider. Uw test moet rekening houden met uw verschillende gebruiksscenario's en gebruikersworkflows. De volgende tabel kan u helpen bij de evaluatie.

CXone-applicatie	Externe IDP	Authenticatieprotocol	Beperkingen en workarounds
CXone-platform en alle applicaties	Alle	Alle	Ondersteunt geen versleuteling van claims.
CXone-platform en alle applicaties	Alle	SAML 2.0	Alleen ondertekenen van berichten wordt ondersteund. Openbaar certificaat moet worden opgenomen in antwoord.
CXone-platform	Azure AD	SAML 2.0	Alleen de IdP-geïnitieerde workflow wordt ondersteund.

Vertrouwen creëren

Identiteitsproviders moeten elkaar vertrouwen voordat ze kunnen communiceren. Dit betekent dat elke provider informatie over de andere moet hebben. Welke informatie vereist is, hangt af van het authenticatieprotocol. De manier waarop de informatie wordt verkregen, is afhankelijk van de IdP.

Vertrouwen in OpenID Connect

Uw CXone-accountmanager zal met u samenwerken om een vertrouwde relatie te configureren tussen uw CXone bedrijfseenheid Een organisatorische eenheid die wordt gebruikt om technische ondersteuning, facturering en globale instellingen voor uw CXone-omgeving te beheren en uw externe IdP met behulp van OpenID Connect.

Vertrouwen in OpenID Connect vereist de volgende gegevens, die u nodig hebt om de relatie te configureren:

• Uitgever – Deze waarde heeft altijd de vorm van een URL, maar kan variëren afhankelijk van uw externe IdP. Google kan bijvoorbeeld als een externe IdP optreden en ondersteunt OpenID Connect. De Google-uitgever is https://accounts.google.com. Veel externe IdP-providers maken hun uitgevers-URL detecteerbaar door ".well-known/openid-configuration" toe te voegen aan het einde van de primaire URL voor de IdP. Dit geeft u vaak waardevolle extra informatie over de IdP. De volgende afbeelding toont de soorten informatie die op deze manier door Facebook worden verstrekt via https://www.facebook.com/.well-known/openid-configuration:

  

• Client-identificatie – Deze waarde wordt door uw externe IdP toegewezen. U gebruikt deze waarde met CXone. Tijdens de authenticatie geeft de client-identificatie aan de IdP door welke applicatie zich probeert te authenticeren.
• Klantgeheim – Deze waarde zorgt dat de authenticatie veilig verloopt, en helpt te verhinderen dat kwaadwillenden de externe IdP kunnen gebruiken om zich te authenticeren bij uw CXone bedrijfseenheid . CXone ondersteunt alleen client_secret_basic en client_secret_post.

Vertrouwen in SAML 2.0

Er zijn verschillende configuratieparameters die worden gebruikt om vertrouwen op te bouwen met SAML 2.0. Werk met uw CXone-accountmanager samen om deze parameters te gebruiken voor het creëren van een vertrouwde relatie tussen uw CXone bedrijfseenheid Een organisatorische eenheid die wordt gebruikt om technische ondersteuning, facturering en globale instellingen voor uw CXone-omgeving te beheren en uw externe IdP.

Veld	Eigenschap
Entiteit-ID	Een vooraf ingevulde, niet-bewerkbare, wereldwijd unieke ID die u mogelijk moet invoeren bij uw externe IdP wanneer u het SAML 2.0-protocol gebruikt. De IdP voegt deze waarde als entiteit-ID van de uitgever toe aan het SAML 2.0-verzoekbericht. Sommige IdP's, zoals Okta en OneLogin, vereisen niet dat u de entiteit-ID aan de kant van de identiteitsprovider configureert. Anderen, waaronder Salesforce, vereisen dit wel.
Eindpunt-URL	De eindpunt-URL die wordt opgegeven door uw IdP.
Bevestiging-URL	Een vooraf ingevulde, niet-bewerkbare URL die uw IdP nodig heeft om een SAML 2.0-flow te configureren. Dit dient als een eindpunt-URL voor het ontvangen en parseren van een authenticatiebevestiging. U moet deze ID invoeren in uw IdP-configuratie, meestal in het veld ACS URL. Sommige IdP's gebruiken een andere naam dan ACS. In het sjabloon Okta SAML 2.0 typt u deze URL bijvoorbeeld in het veld Single Sign On URL.
Certificaat	U krijgt van uw IdP een beveiligingscertificaat.

Authenticatie van applicaties

Gebruikers en applicaties worden op vergelijkbare manieren geauthenticeerd. Het belangrijkste verschil is dat applicaties worden geauthenticeerd met een toegangssleutel, terwijl gebruikers worden geauthenticeerd met een gebruikersnaam en wachtwoord. In tegenstelling tot gebruikers zijn applicaties niet verplicht om via een browser te communiceren. Applicaties kunnen functioneren in een backoffice-omgeving.

U kunt een gebruikersprofiel instellen voor een applicatie (in plaats van voor een gebruiker). Hiervoor maakt u het gebruikersprofiel, geeft u het profiel een naam die verwijst naar de applicatie en genereert u een toegangssleutel. CXone regelt de authenticatie van applicaties intern. Applicaties kunnen niet worden geverifieerd bij externe identiteitsproviders.

Autorisatie in CXone

Autorisatie is het proces om te bepalen tot welke bronnen een gebruiker toegang heeft. Bronnen zijn bijvoorbeeld applicaties, bestanden en gegevens. U kunt de toegang van gebruikers tot bronnen instellen met behulp van beveiligingsprofielen. CXone regelt tijdens het inlogproces de autorisatie automatisch. Nadat gebruikers zijn geauthenticeerd, krijgen ze alleen toegang tot de bronnen waarvoor ze zijn geautoriseerd.

De authenticatiemethode van een gebruiker heeft geen gevolgen voor de autorisatie. CXone gebruikt hetzelfde autorisatieproces voor alle gebruikers. Het maakt niet uit of ze zijn geauthenticeerd met behulp van toegangssleutels of wachtwoorden.