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.
Gebruikers kunnen mensen zijn, maar ook applicaties. Chatbots en virtuele assistenten hebben vaak een eigen gebruikersaccount. De meeste applicatiesuites gebruiken dezelfde procedure menselijke en virtuele gebruikers. In deze online Help-pagina's over authenticatie en autorisatie bedoelen we met de term gebruiker zowel mensen als applicaties. Waar er sprake is van verschillen, worden deze duidelijk uitgelegd.
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:
-
Een gebruiker krijgt toegang tot CXone via een ondersteunde webbrowser.
-
CXone vraagt om de inloggegevens van de gebruiker.
-
De gebruiker voert de inloggegevens in.
-
CXone verifieert de gegevens bij een identiteitsprovider (IdP). CXone heeft een ingebouwde IdP, maar kan ook werken met een externe IdP.
-
Nadat de gebruiker is geauthenticeerd, geeft de CXone-autorisatieserver toegang tot het CXone-platform. CXone ondersteunt geen externe autorisatiesystemen.
Authenticatie met 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
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
Wachtwoorden zijn niet zichtbaar in CXone. Vanwege de privacy en de veiligheid worden wachtwoorden intern bijgehouden en kunnen ze alleen worden gewijzigd via een workflow voor 'wachtwoord vergeten' of 'wachtwoord resetten'. Gebruikers kunnen hiervoor de link op het wachtwoordscherm gebruiken en de instructies op het scherm volgen. Gebruikers zullen een e-mail ontvangen die hen laat weten of hun wachtwoord gewijzigd is.
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
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 worden toegewezen aan rollen. Dit betekent dat de authenticatiemethode van een medewerker afhankelijk is van de rol die aan de medewerker is toegewezen.
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
Door IdP gestarte flows zijn van toepassing op individuele applicaties, niet op de volledige CXone-suite. U kunt deze flow bijvoorbeeld gebruiken om de toepassingen van de hoofdgebruikersinterface te starten, maar u kunt deze niet gebruiken om andere applicaties, zoals Studio, te starten. Voor een naadloze werking van de volledige suite, is de door SP gestarte flow vereist.
Authenticatieprotocollen ondersteunen de communicatie en het vertrouwen tussen verschillende IdP's. CXone ondersteunt een authenticatieprotocol genaamd SAML 2.0.
SAML 2.0 is een gevestigde technologie en wordt nog op grotere schaal gebruikt dan nieuwere technologieën zoals OpenID Connect. Deze technologie ondersteunt 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, IdP-geïnitieerde workflow. Bij deze workflow voeren uw gebruikers hun inloggegevens in bij uw IdP. Vervolgens start de IdP CXone.
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.
CXone biedt geen ondersteuning voor aanvullende versleuteling die wordt aangeboden door sommige authenticatieprotocollen.
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 | Alle | OpenID Connect | Niet ondersteund. |
Alleen de hoofdwebapplicaties ondersteunen de door IdP gestarte SAML 2.0 flow. Gebruikers die toegang vereisen tot Studio of de verschillende agentapplicaties, moet de ingebouwde authenticatie of een door SP gestarte flow gebruiken.
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.
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 CXonetenant Een organisatorische eenheid die wordt gebruikt om technische ondersteuning, facturering en globale instellingen voor uw CXone-omgeving te beheren en uw externe IdP.
Veld |
Details |
---|---|
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
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
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.